I'm only part of the way through this book, so I can't claim to know all about it. I bought it because the author (and possibly other reviews I'd read?) stated that the book helps illustrate how to approach a problem using regular expressions.
You can hand me a box of wrenches, but that won't tell me how to fix a car.;-)
...you consult DSLReports when researching places to live. Been there, done that -- in St. Louis, no less.
But hey, I completely understand that not everyone is as socially deprived as I am. I verified not only the distance to the CO, but how their feature set compared to the CO in the neighborhood from which I was moving. Not that I understand what a CO being an "OC12 capable wire center" truly means, but anything mentioning OC12 has to be cool, right?;-)
I'm a T-Mobile customer in St. Louis (I live in the city), and except for a few dead cells here and there is pretty thoroughly covered.
This plan seems interesting. It says $29.99/mo for unlimited access, but curiously lists $0.20/minute for calls. T-Mobile uses GSM, which means this data connection is probably provided via GPRS, so it's not technically using a call to do so. (Sidenote: I know from experience that unless you specifically have GPRS added to your plan, T-Mobile will handle Internet access as a phone call, charging you minutes. Thus, while Internet access on a GSM line seems like it would always be GPRS, this isn't the case.) At any rate, it's not totally clear what all this plan offers. It would be nice to know if they would add this on to a standard phone plan of theirs so you don't have to pay for minutes.
Don't assume they'll do this unless you ask. They can be pretty goofy about the plans they'll let you set up. Good luck!
The system includes software-based motion detection. Each camera sends an encrypted image to a central location (US HomeGuard data center) that decrypts it and uses software to compare whether the image changed since the last screen shot. If so, it sends this "suspect" image to one of the watchers. If the watcher indicates the image is suspicious, the system sends it and similar pictures to several reviewers. If they declare it suspicious, then professionals take over.
The system is looking at areas where people aren't supposed to be. Anyone/anything in this area shouldn't be there.
In theory, invalid targets such as stray cats could be weeded out by the image-detection software.
I honestly will not buy a technical book in the 1,000+ page range, especially if the title:
Includes the words "bible", "unleashed", or "secrets"
Is entitled Learn x in y days/hours
Why? Because I know I'm unlikely digest the contents of 1000+ pages of text on one subject, if I manage to finish it. I also generally suspect large books of rehashing FAQs or other widely-available docs just to fill pages.
I don't consider myself an O'Reilly bigot, though I do lean towards their books since they tend to publish smaller, focused books. If a book is pure reference, I may consider buying it if it's 1000+ pages. Following are examples of some great books I've bought that I found very useful and readable due to their small size:
The Internet already offers me an overwhelming, disorganized pile of information on any subject--and at least it's searchable via Google. Dead tree books have use when they're usable and organized, and I've found that generally translates into a smaller book.
First, we have to get a few assumptions out of the way. Let's assume that we're dealing with IBM/Hollerith punch cards, so we can standardize. Now, let's pretend that these cards hold 80 bytes. The card's design predated ASCII, so while there were 12 punches per character, they didn't even represent as much data as a byte. (Follow the link for more.) So, rather than pretend they're 12 bits * 80, let's assume they were used for more or less today's equivalent of 80 bytes. And, in keeping with the hard drive manufacturers' "truth" in advertising, I'm going to assume that 1TB = 1,000,000,000,000 bytes.
Whew, now that we established those assumptions, 1TB of punch cards would be 12,500,000,000 cards.
Assuming the strict standard dimensions under which these cards were produced, we can say that this stack of cards would be ~1,322 miles high +/- ~99 miles. In terms of volume, these cards would take up ~43,025 cubic yards (+/- ~3,211 cu yds). Assuming roughly 100,000 cu yds of concrete for a major-league baseball stadium (seems to vary a fair amount by stadium design), it would take roughly 2.3 TB of punchcards to equal the volume of concrete in a stadium.
Aww, man, I realized I didn't subtract the volume loss for the diagonal-cut top left corner. Someone else can take that.
Were you using the 3Ware 7810 or the 7850 controller? I'm just curious because the 7850 supposedly has higher RAID5 throughput though it seems according to their specs the higher throughput primarily occurs with small random reads/writes.
I'm assuming the "RAID 0 over 5" description is because you're running each controller as a RAID 5 array, then using software RAID to stripe these as a RAID 0 array? I'm currently spec'ing out a system that would use this arrangement, so it's nice to hear someone else [seems to be] doing this.
I sure don't. I live in a good-sized city, but the problem is that all of the stations seem to want to attract all of the listeners. So instead we have several stations playing a mix of genres. I like lots of music genres sold in stores but can't think of the last time a radio station played a song that made me want to buy an album. NPR is an exception, but on NPR I've learned of artists by listening to talk radio.
The big labels don't tell you anything, but smaller labels are excellent for finding good music. 4AD (ex. Cocteau Twins, Lisa Gerrard, Dead Can Dance) is a great label. IRS records, run by the Copeland boys, used to be a great source, and now they run Ark21 that delivers some really interesting stuff. And back in the day when "New Age" wasn't laughted at, Narada and Windham Hill were respected labels.
I've learned from others' kind rebuke that there is some relationship between Bernoulli's principle and the results of Dr. Schmidt's research. However, I still think it's important to recognize that the reason this item was deemed press-worthy is because it did something a little more than what Bernoulli did.
Sorry if I was a little rude in my initial response. I feel like many, many posters have made no attempt to even read the NYT article. (I'll confess I only read the NYT article and didn't read the UMass press release.)
Seeing how you actually thought this through, and know more about the subject than I do, I respect your opinion that traditional experimentation would've revealed the answer. However, I quite frankly don't know enough to agree or disagree with you.
What I believe you so cleverly concluded was that Bernoulli's principle was at work. If you had read the article, you would have seen that Dr. Schmidt's research had nothing to do with the Bernoulli principle.
I seriously doubt that you reasoned out that the eye of a sideways hurricane was causing the vacuum in your shower, but perhaps I'm wrong.
Hey Rain Man, I would've simply been impressed if you'd come up with the Bernoulli principle with no outside assistance. But instead, you "assumed" that the eye of a miniature sideways hurricane pulled in the shower curtain--at the age of eight?
I think it's valuable for bosses to attend, but not run, code reviews. They'll probably get bored with the details, but I think it helps them understand the technical concepts behind the code.
Consider adherance to basic coding standards a prerequisite to the review. Don't waste everyone's time pointing out that you misnamed variables in 20,000 places. Instead, let the code review catch the three places you missed. As part of this, enforce and refine the important part of coding standards: providing stable, maintainable code. I've been involved in many tense, anger-filled discussions trying to agree upon the one correct way to skin a cat (don't know if that expression is internationally used: in case you're confused, I'm not talking about mutilating animals:-). Avoid issues of style. Easier said than done, because it's really hard to determine what's style and what's important. I consider this a fairly subjective process. Following are examples to show what I consider important or not:
Important: variable naming. Use descriptive variable names, and some agreed-upon variation of Hungarian notation. Naming differences could cause ugly bugs in the future when one group uses a prefix 'p' to indicate parameter and another uses it to indicate a variable is a pointer. (That's a real-life example.) Besides, proper naming is easy, and I consider it part of fundamental code documentation.
Important: method/property names. As with variable naming, it's not that hard to do, and I consider it an integral part of program documentation. Here are some of the common rules I think are good, and easy/flexible enough to not let people feel like The Man's holding back their creativity:
Methods should start with a verb if possible.
Property names should be specific.
Methods with a Boolean return value are good to word as a question (examples: IsMissing, Exists). It's clear to the caller even without looking at the declaration to realize what type of value is coming back, and also makes logic using such methods self-documenting.
Important: namespace collision. Not a huge deal, but it's good to make sure that any namespace collision is intentional. For example, if you have two general function libraries, having a method ValidateData() is probably a bad idea. However, if two objects each have a Validate method, that would make sense. Yes, this is more a design thing, but for those of use where code reviews are rare, design reviews are even harder to find.
Unimportant: choice of control structure. if..then..else is okay, and so is switch..case. In general, for..next == repeat..until == do..while == while..wend == foreach..next. It's not always irrelevant, but make sure you really have a good reason for suggesting your choice, and it's not a good reason to say "XYZ magazine said that in version 4.09 a while loop is 8% faster than for..next."...which provides a segue into an even more controversial opinion:
Unimportant: efficiency. Okay, I admit I just worded it that way for effect. It depends on your application. I work as a corporate developer writing business applications used in-house only. I firmly believe in our environment it's important to write applications focused on maintenance and reuse. In unit testing, look for efficiency problems. A problem means that your application will do something that your users will find clunky or slow. I am NOT talking about memory leaks. Memory leaks are bugs, period. For example, I'm talking about poo-pooing crossing process boundaries in cases where it's demonstrated that such interprocess communication is not an application bottleneck.
Use code reviews to develop coding standards. It's okay if you don't have coding standards, but once you debate a style issue, document it so you don't have have that debate again.
Code reviews are great CYA. Let's say Developer A gets to maintain Developer B's code. Now, if Developer A is cutthroat/incompetent/lazy/insecure, they might be inclined to rip on Developer B's code as they're looking at it, possibly in the earshot of peers or managers. Involve your peers in the code review in the first place! I think it can shut up a lot of people. They have an opportunity to openly rip on your code, in front of the boss and everything. In my experience, folks shy away from such openness -- and if they do rip on your code and have a valid point, a better application is the result. If they're wrong, they get pointed out as wrong. (Yes, politics could get in the way here -- possibly I've just been lucky in not seeing this be a problem.)
Make code review attendance mandatory. Not in a "do it or else" sense, but in a sense of "do, or if not make sure you have a good reason, pre-approved by your manager, why you cannot participate." Code reviews are not fun, but I think you can learn a lot about good coding practices by questioning another or by having to answer questions about how you do things.
Code reviews can help reuse. In code reviews I've gotten a chance to see code worked on by other developer groups, and saw some neat objects that I've since used in my applications. I think politics (and time schedules) can get in the way of some formal sharing and reuse. This lurking type of sharing/reuse has helped me on more than one occasion. (Yes, I leave the original programmer's comment headers in place to give credit where it's due:-)
OSS worse for nuisance, better for real problems
on
New Linux Worm
·
· Score: 1
When problems are more widely discussed and understood, they allow the common Internet vandal (script kiddie) the ability to point and click their way through denial of service attacks, web site defacement and the like.
They don't scare me the way the real criminals do: the ones that are serious and determined, and who are good enough to not get caught. I doubt these guys/gals share the tricks of the trade.
Now, let's shift focus to closed-source software. Most if not all closed-source software is, for obvious reasons, owned by companies interested in making a profit. Naturally, the larger the install base, the larger the company. Big companies move slowly at doing nearly everything. What business sense would there be in a big company announcing a problem before they had a solution?
I'd wager that nearly every time a closed-source software package has released a security-related patch, any number of people have been quietly exploiting these scary problems.
I'd prefer to have no security holes, but if I had to choose I'd rather face a script kiddie than an experienced, determined cracker....
This is just a crackpot theory I have, but I attended VBITS last fall and Microsoft was there in full force touting the benefits of the recently unveiled.NET initiative.
I found it interesting that MS folks talked about the openness one gains via.NET, but seemed to carefully use examples that praised Linux, and mentioned other OSS-friendly languages (Python & Perl) as working with.NET. My thought is that they figure if you have to choose an outsider to shake hands with, pick OSS, since it's easier to FUD your way through sales pitches against OSS than a publicly-traded, for-profit company.
Anyway, I thought someone might find this thought interesting to consider, but take it for the basis-free speculation that it is....
It's great to have the freedom to choose your GUI, but as a developer, it's a bummer to try to think about how to write a GUI application for Linux.
I'm a VB developer by day, but looking to learn more about Linux development. Setting aside the obligatory M$-bashing for a moment, in VB I can easily write a silly little GUI app that my friends can run on their machines, and probably anyone with win9x/NT/2K could run as well. (I'm talking about the ease of GUI development, not scalability, stability, or portability. I think portability, while clearly valuable to GUI developers, simply isn't there yet. In theory Java can do it, but I have yet to see it.) I'm not sure I see the availability of a ubiquitous GUI tool for Linux, but someone please correct me if I'm wrong.
Console vs. GUI -- that's a clear demarcation. But KDE vs. GNOME vs. whatever-else? I think it would make Linux more accessible to the masses if there were a universal GUI choice.
That's great if you're given a project with thorough specs up-front that don't change through the development process. For many good and bad reasons, requirements often change mid-project, or are handed to you with missing parts that you're told will be filled in later. I doubt I'm the only programmer that's been faced with this set of working circumstances.
Of course it's not how you're supposed to write code, but an employer simply wants you to provide a workable solution in an amount of time that the business needs dictate.
I've found the niceties such as reusability and maintenance go out the window in favor of speed of implementation. Of course, one could successfully argue the merits of following proper design principles. However, the business can also present a solid case on why a flawless application delivered long after it was needed (possibly late enough that the requirements are obsolete) is worthless, while an imperfect system that mostly meets deadlines and requirements is at least worth their money.
Slashdot Mirror
Greatest PC ever: not a chance. But really good for $450, and I think meeting your specs of "decent" quality.
You can hand me a box of wrenches, but that won't tell me how to fix a car. ;-)
But hey, I completely understand that not everyone is as socially deprived as I am. I verified not only the distance to the CO, but how their feature set compared to the CO in the neighborhood from which I was moving. Not that I understand what a CO being an "OC12 capable wire center" truly means, but anything mentioning OC12 has to be cool, right? ;-)
This plan seems interesting. It says $29.99/mo for unlimited access, but curiously lists $0.20/minute for calls. T-Mobile uses GSM, which means this data connection is probably provided via GPRS, so it's not technically using a call to do so. (Sidenote: I know from experience that unless you specifically have GPRS added to your plan, T-Mobile will handle Internet access as a phone call, charging you minutes. Thus, while Internet access on a GSM line seems like it would always be GPRS, this isn't the case.) At any rate, it's not totally clear what all this plan offers. It would be nice to know if they would add this on to a standard phone plan of theirs so you don't have to pay for minutes.
Don't assume they'll do this unless you ask. They can be pretty goofy about the plans they'll let you set up. Good luck!
I honestly will not buy a technical book in the 1,000+ page range, especially if the title:
Why? Because I know I'm unlikely digest the contents of 1000+ pages of text on one subject, if I manage to finish it. I also generally suspect large books of rehashing FAQs or other widely-available docs just to fill pages.
I don't consider myself an O'Reilly bigot, though I do lean towards their books since they tend to publish smaller, focused books. If a book is pure reference, I may consider buying it if it's 1000+ pages. Following are examples of some great books I've bought that I found very useful and readable due to their small size:
The Internet already offers me an overwhelming, disorganized pile of information on any subject--and at least it's searchable via Google. Dead tree books have use when they're usable and organized, and I've found that generally translates into a smaller book.
First, we have to get a few assumptions out of the way. Let's assume that we're dealing with IBM/Hollerith punch cards, so we can standardize. Now, let's pretend that these cards hold 80 bytes. The card's design predated ASCII, so while there were 12 punches per character, they didn't even represent as much data as a byte. (Follow the link for more.) So, rather than pretend they're 12 bits * 80, let's assume they were used for more or less today's equivalent of 80 bytes. And, in keeping with the hard drive manufacturers' "truth" in advertising, I'm going to assume that 1TB = 1,000,000,000,000 bytes.
Whew, now that we established those assumptions, 1TB of punch cards would be 12,500,000,000 cards.
Assuming the strict standard dimensions under which these cards were produced, we can say that this stack of cards would be ~1,322 miles high +/- ~99 miles. In terms of volume, these cards would take up ~43,025 cubic yards (+/- ~3,211 cu yds). Assuming roughly 100,000 cu yds of concrete for a major-league baseball stadium (seems to vary a fair amount by stadium design), it would take roughly 2.3 TB of punchcards to equal the volume of concrete in a stadium.
Aww, man, I realized I didn't subtract the volume loss for the diagonal-cut top left corner. Someone else can take that.
( As always, props to Google for my research. :-)
Were you using the 3Ware 7810 or the 7850 controller? I'm just curious because the 7850 supposedly has higher RAID5 throughput though it seems according to their specs the higher throughput primarily occurs with small random reads/writes.
I'm assuming the "RAID 0 over 5" description is because you're running each controller as a RAID 5 array, then using software RAID to stripe these as a RAID 0 array? I'm currently spec'ing out a system that would use this arrangement, so it's nice to hear someone else [seems to be] doing this.
I sure don't. I live in a good-sized city, but the problem is that all of the stations seem to want to attract all of the listeners. So instead we have several stations playing a mix of genres. I like lots of music genres sold in stores but can't think of the last time a radio station played a song that made me want to buy an album. NPR is an exception, but on NPR I've learned of artists by listening to talk radio.
The big labels don't tell you anything, but smaller labels are excellent for finding good music. 4AD (ex. Cocteau Twins, Lisa Gerrard, Dead Can Dance) is a great label. IRS records, run by the Copeland boys, used to be a great source, and now they run Ark21 that delivers some really interesting stuff. And back in the day when "New Age" wasn't laughted at, Narada and Windham Hill were respected labels.
I've learned from others' kind rebuke that there is some relationship between Bernoulli's principle and the results of Dr. Schmidt's research. However, I still think it's important to recognize that the reason this item was deemed press-worthy is because it did something a little more than what Bernoulli did.
Sorry if I was a little rude in my initial response. I feel like many, many posters have made no attempt to even read the NYT article. (I'll confess I only read the NYT article and didn't read the UMass press release.)
Seeing how you actually thought this through, and know more about the subject than I do, I respect your opinion that traditional experimentation would've revealed the answer. However, I quite frankly don't know enough to agree or disagree with you.
What I believe you so cleverly concluded was that Bernoulli's principle was at work. If you had read the article, you would have seen that Dr. Schmidt's research had nothing to do with the Bernoulli principle.
I seriously doubt that you reasoned out that the eye of a sideways hurricane was causing the vacuum in your shower, but perhaps I'm wrong.
Hey Rain Man, I would've simply been impressed if you'd come up with the Bernoulli principle with no outside assistance. But instead, you "assumed" that the eye of a miniature sideways hurricane pulled in the shower curtain--at the age of eight?
You are describing the Bernoulli principle. The article states why Dr. Schmidt's research observed something different from the Bernoulli principle.
Read the article. Read the article. Read the article....
Use code reviews to develop coding standards. It's okay if you don't have coding standards, but once you debate a style issue, document it so you don't have have that debate again.
Code reviews are great CYA. Let's say Developer A gets to maintain Developer B's code. Now, if Developer A is cutthroat/incompetent/lazy/insecure, they might be inclined to rip on Developer B's code as they're looking at it, possibly in the earshot of peers or managers. Involve your peers in the code review in the first place! I think it can shut up a lot of people. They have an opportunity to openly rip on your code, in front of the boss and everything. In my experience, folks shy away from such openness -- and if they do rip on your code and have a valid point, a better application is the result. If they're wrong, they get pointed out as wrong. (Yes, politics could get in the way here -- possibly I've just been lucky in not seeing this be a problem.)
Make code review attendance mandatory. Not in a "do it or else" sense, but in a sense of "do, or if not make sure you have a good reason, pre-approved by your manager, why you cannot participate." Code reviews are not fun, but I think you can learn a lot about good coding practices by questioning another or by having to answer questions about how you do things.
Code reviews can help reuse. In code reviews I've gotten a chance to see code worked on by other developer groups, and saw some neat objects that I've since used in my applications. I think politics (and time schedules) can get in the way of some formal sharing and reuse. This lurking type of sharing/reuse has helped me on more than one occasion. (Yes, I leave the original programmer's comment headers in place to give credit where it's due :-)
When problems are more widely discussed and understood, they allow the common Internet vandal (script kiddie) the ability to point and click their way through denial of service attacks, web site defacement and the like.
They don't scare me the way the real criminals do: the ones that are serious and determined, and who are good enough to not get caught. I doubt these guys/gals share the tricks of the trade.
Now, let's shift focus to closed-source software. Most if not all closed-source software is, for obvious reasons, owned by companies interested in making a profit. Naturally, the larger the install base, the larger the company. Big companies move slowly at doing nearly everything. What business sense would there be in a big company announcing a problem before they had a solution?
I'd wager that nearly every time a closed-source software package has released a security-related patch, any number of people have been quietly exploiting these scary problems.
I'd prefer to have no security holes, but if I had to choose I'd rather face a script kiddie than an experienced, determined cracker....
This is just a crackpot theory I have, but I attended VBITS last fall and Microsoft was there in full force touting the benefits of the recently unveiled .NET initiative.
.NET, but seemed to carefully use examples that praised Linux, and mentioned other OSS-friendly languages (Python & Perl) as working with .NET. My thought is that they figure if you have to choose an outsider to shake hands with, pick OSS, since it's easier to FUD your way through sales pitches against OSS than a publicly-traded, for-profit company.
I found it interesting that MS folks talked about the openness one gains via
Anyway, I thought someone might find this thought interesting to consider, but take it for the basis-free speculation that it is....
Thanks! I'm going to look into what you're suggesting with XDesigner/Motif.
It's great to have the freedom to choose your GUI, but as a developer, it's a bummer to try to think about how to write a GUI application for Linux.
I'm a VB developer by day, but looking to learn more about Linux development. Setting aside the obligatory M$-bashing for a moment, in VB I can easily write a silly little GUI app that my friends can run on their machines, and probably anyone with win9x/NT/2K could run as well. (I'm talking about the ease of GUI development, not scalability, stability, or portability. I think portability, while clearly valuable to GUI developers, simply isn't there yet. In theory Java can do it, but I have yet to see it.) I'm not sure I see the availability of a ubiquitous GUI tool for Linux, but someone please correct me if I'm wrong.
Console vs. GUI -- that's a clear demarcation. But KDE vs. GNOME vs. whatever-else? I think it would make Linux more accessible to the masses if there were a universal GUI choice.
That's great if you're given a project with thorough specs up-front that don't change through the development process. For many good and bad reasons, requirements often change mid-project, or are handed to you with missing parts that you're told will be filled in later. I doubt I'm the only programmer that's been faced with this set of working circumstances.
Of course it's not how you're supposed to write code, but an employer simply wants you to provide a workable solution in an amount of time that the business needs dictate.
I've found the niceties such as reusability and maintenance go out the window in favor of speed of implementation. Of course, one could successfully argue the merits of following proper design principles. However, the business can also present a solid case on why a flawless application delivered long after it was needed (possibly late enough that the requirements are obsolete) is worthless, while an imperfect system that mostly meets deadlines and requirements is at least worth their money.
Well, as long as you like to listen to "mrf wrfn brpn mmm" ...