Then I must vehemently disagree with your vehement disagreement. On a web site, for example, my "business logic" says that a new registration must be added to the member database, to certain groups, to a log (another database), to a email list (another server), and a registration notice sent (another server).
Looks like we have a definition of terms problem. Most of what you mentioned is what you previously called "Application logic". My question was whether or not you really meant "Application logic" or "Business logic", where "Business logic" is "actions applied to your data" and "Application logic" is "actions using your data" (yes, "Business logic" isn't really a good name for this, but it's what we've got). The only piece of business logic in what you mentioned is the insert into the database. In this case, it's extremely trivial business logic, but it's still business logic. As such, I'd say it merits a stored procedure, for the obvious reasons (you may have some logic around how you insert into the database, including relations and such) and the not so obvious reasons (stored procedures, when implemented and called correctly, protect against SQL injection attacks, increase performance, abstract your data layer by providing a consistent interface even when the underlying structure may change, keep your data logic close to the data, allow you to make updates to said logic without affecting your client apps, and simplify permissions by allowing you to grant EXECUTE access to only the procedures needed by an app rather than figuring our your SELECT, INSERT, UPDATE, and DELETE permission chains).
I paid good money to have my database server serve data, and that's ALL I want it doing.
Then you got ripped off. A database engine can be much more than an alternative file system. Maybe you don't really have any complex data needs, but that doesn't negate the ability of a database engine to do real work.
"Stored procedures" written in C# should really be thought of in the same way as the extended procedures from SQL Server 2000. In otherwords, you probably will never use that feature, and if you do find that you need it you must really scrutinize why and the security implications of doing so. In most cases, you're better off with straight T-SQL procedures, and that hasn't changed for SQL Server 2005.
Personally, I haven't yet found a good reason to use C# stored procedures, but I'm also not using SQL Server 2005 yet. When my team migrates in the coming months, I might change my tune, but for now I'm more interested in other feature enhancements like try/catch error handling semantics and the snapshot isolation levels (allows for better concurrency without having to risk dirty reads by using (nolock) or setting a "read uncommitted" isolation level).
Stored procedures are one of those things that are like antibiotics or LSD - they're wonderful and valuable when handled carefully and responsibly, and cause big problems when they're not.
Do you have examples of procedures gone horribly wrong? Preferably not something completely obvious, like a proc that takes a varchar(8000) as input and just passes that to exec (completely stupid, negates all of the benefits of using stored procs). From my experience, you're better off using stored procedures than dynamic SQL in your code, so long as a few sanity check requirements are in place -- limit the amount of dynamic SQL in your procedures, prefer table variables over temp tables (to prevent recompilations), and general T-SQL best practices: limit your use of cursors and looping since SQL is a set-based language, keep your transactions as short as possible, avoid forcing index hints, count() on an indexed column or better yet * (allows the plan engine to pick the best column to count on), etc.
The limited stored proc language that SQL server had before was actually a good thing; you could do some limited stuff in the DB. Thus, you weren't often able to give in to the tendency to stick application logic in the database tier.
Depends on what you mean by "application logic". If you meant to say "business logic", then I must vehemently disagree -- business logic should live close to the data, in a reusable form so it need not be implemented in each app that wants to use the data. Ideally that means stored procedures. If you can't implement your business logic in T-SQL, then you need to re-think your logic requirements and your schema. If it still can't be done, then you can go ahead and start moving it into external libraries, but you should try your best to keep your logic as close to your data as possible.
gDesklets and Konfabulator are available only for Gnome/KDE based systems.
Just because Konfabulator starts with a 'K' doesn't mean it's a KDE tool. In fact, it doesn't even run on Linux, but Windows and Mac OS X. Oh yeah, and it's owned by Yahoo now, too. Looks like gadgets, widgets, and sidebars are the new battelground, with Yahoo, Apple, Microsoft, and now Google in the mix. Yahoo has a serious lead, since Konfabulator is the oldest product.
Now there is something on the.NET platform that Microsoft is making called "Atlas". It builds on AJAX but allows a developer to write ASP.NET server controls that render AJAX-ish code. At least that's the concept, I believe. Will be nice to see how it pans out.
For what it's worth, Live.com (and Start.com before it) uses Atlas. Building Gadgets for Live.com/Start.com is a good way to get your feet wet with Atlas, though they could do a better job of providing documentation.
Microsoft is in the position IBM was years ago and they are just beginning to realize the effect of Google and it seems a bit too late now......a lot of Microsoft's current offerings aren't all that appealing or innovative compared to Googles and other companies.
Alternatively, Microsoft is in the same position as they were a decade ago, with Google now playing the role of Netscape. We all know how that ended.
I saw some HTML + webified versions of Office when I worked there. Probably around 2000. They cancelled it. I wish I could remember more about it.
Most likely you're thinking about NetDocs, which, though it never shipped as a single product, did actually contribute many pieces to Office (InfoPath in particular), MSN (parts of their billing and support system, Messenger, pieces of MSN Explorer), and other Microsoft products that did ship. Alternatively, you might have seen pieces of Hailstorm, which was later named ".NET My Services" before being killed. Again, much of Hailstorm's knowledge made its way into.NET (Hailstorm was all about Web Services right when the whole.NET thing was starting up, and it's no coincidence that.NET has very robust support for SOAP-based web services).
This is not all that different from what other companies do, with the exception of Microsoft publicizing projects that are eventually killed or integrated into something else. This is not even unusual for Microsoft. For example, where do you think the Office Assistant (Microsoft Agent) stuff came from? Microsoft Bob (especially the dog and cat). While it was patronizing and simplistic, it was also way ahead of its time -- task-based interface, scaleable vector graphics, "interactive" help (say what you will about Clippy and the Office Assistant crap, but many people liked them and you can't really argue with the cuteness factor), etc. This is how companies grow and innovate. What Microsoft learned from Hailstorm surely has a direct effect on Windows Live, just as what they learned from NetDocs affected Office and what they learned from Bob affected Windows and Office. For example, they've learned to use open betas to their advantage, and to incubate fresh ideas with little intervention (Start.com, the origin of Live.com and arguably the cornerstone to the whole project, was developed, shipped, and supported by a team of only two or three developers with no management overhead or other BS, and who were allowed to be open about the process through blogging and customer interaction -- they were even allowed to support Firefox!).
People scoffed at the first couple versions of Internet Explorer, but when Microsoft got fired up they really blew everybody away. Hopefully this time they've learned that follow-through is just as important as shipping, and Windows Live doesn't stagnate the way IE did.
My sentiments exactly except I don't think they even tried to extend it. It's a somewhat anemic version of the Google Personal Homepage with nary a hope of ever catching up. I am confounded by the "Windows Live" aspect, but in fairness it is in Beta. Perhaps an Internet based bootable OS is right around the corner. From Microsoft I mean. BWAHAHAHAHHAHAAAAHAHAHHAHAH!!!!
Have you even tried using Live.com? Sure, it's superficially like Google's personalized home page, but it does more than that. First off, Live.com is from the Start.com project, which has been around longer than Google's personal page (as others have already pointed out), and thus Google is copying Microsoft. BWAHAHAHA. Ahem. Second, Live.com is more "slick", for lack of a better word. You can change the number of columns (want 2 columns instead of 3? only 1 long column?), and the interface just feels "smoother" than Google's (not sure if it's the colors, fonts, icons, or what, and I'll agree that this is really personal preference).
Third, and probably most importantly, Live.com is much more customizable than Google's page. Sure, you can add or remove certain canned items or create a new "section" from a search or a feed on Google's page. You can do that on Live.com as well. However, you can also write your own "gadgets" to add on to the page that are not just RSS feeds. I'm sure Google has the knowledge and talent to be able to do something like that, but you can't deny that Live.com does things Google Personal doesn't.
As for the name "Windows Live", the Slashdot article title is just completely stupid. This is not an "Internet Version of Windows", but a companion. The "Live" naming obviously comes from Xbox Live, which is not an "Internet Version of Xbox" but a companion service that allows you to communicate and interact in new and interesting ways with your Xbox ("new" and "interesting" as applied to Xbox, as online gaming, voice chat, and friends lists have all obviously been done elsewhere before Xbox Live). "Windows Live" is obviously aiming at that same idea. Whether they get there or not is still yet to be seen, but at least they're trying. That the beginning looks like stuff we've already seen (though to be fair, we did see it from Microsoft before Google) isn't the point. Go to Windows Live Ideas and look at some of the stuff that's coming. Live Mail is just parity, but Windows Live Safety Center looks pretty cool, as does Windows Live Favorites (okay, so it only imports from IE and not Firefox, but a) it is Beta, and b) it is still Microsoft...). And it sounds like this is just the beginning. Maybe the whole Windows Live thing will fizzle out with nothing more than a neat portal and a modern web mail client, but it could also turn into something really cool.
We've had good results using Sharepoint (hey, you said you were using Microsoft products) to track documents, schedules, tasks, todo lists, etc. It's not as robust as a full source control system like Subversion, but it works well for management stuff (bonus: it's all web-based, so you don't need a local client or enlistment). For binary files like Word or Project files, you really need a method of locking the file. SVN and CVS are really geared towards concurrent changes in text files that are mergeable, so they're not so great for binaries.
Sharepoint is also really useful for lists. In fact we tracked our last release entirely through Sharepoint, from building task lists to release schedules, tracking bug counts and resolution rates, etc. I'm sure there are other solutions out there besides Sharepoint, but Sharepoint is what I have experienced. For example, it shouldn't be difficult to find or write a web interface to Subversion or CVS that will eliminate the need for managers to run enlistment updates just to make sure they have the latest version of a doc. Of course developers should continue to have local enlistments, as they're more efficient that way.
Maybe Microsoft can sell me a game for $60, then nickel and dime me for another $30 so I can download newer textures. What a fanfuckingtastic business model. Oh yeah, they're in this "for the gamers."
First off, only EA has said they'll be pricing games at $60. In fact, Microsoft has said that all of their 360 launch titles will be at $50 or less ($60 for the two-disk PDZ collector's edition). One could extrapolate that future Microsoft titles will be $50 or less, too, but I won't go there.
Second, there's always talk of selling stupid crap like textures or weapons or whatever via Live. It happened with Xbox Live a couple of years ago, and it's happening now with the 360 revision. That doesn't mean it will happen. So far, premium content on Live has been truly "extra" stuff. New maps in Halo 2 (which, BTW, were eventually released for free as well), new cars and tracks in PGR2, etc. And they weren't "one map/car/track at $5", either, but a bundle of several maps, several cars and tracks at $5. Points will allow for micropayment-like transactions so that you could theoretically buy one of the cars for $0.25 instead of all 9 for $5.
Finally, please keep in mind that while Live is a big selling point, the 360 (as the Xbox before it) still needs to be accessible to people without broadband (even though Live Silver is free and comes with every 360, you still may not have the required broadband). Thus, you're not going to buy just a game engine for $60 and be nickled and dimed trying to buy all of the models, textures, and maps needed to make a full game. As well, Microsoft doesn't allow developers to charge for patches that fix problems, so you're not going to see a case where you buy a $60 game and then have to spend another $5 for a bunch of bug fixes.
Be paranoid all you like, but it helps to actually understand what you're scared about first.
Because, Mr. It's-Already-Solved-In-A-Way-All-People-Understand -Quickly, to those basic windows users and spoiled mac users, your installations *are* _very_ often still quite difficult and/or confusing!
So what? That doesn't belong in a review. It belongs in a howto or manual. And please note that I have nothing against a sentence or two, maybe even a paragraph discussing installation. What I'm arguing against is spending 50%+ of a review covering installation. That's just silly. Most people will eventually be able to get the OS installed, at which point they want to know how the rest of the system works. Focusing on installation is like raving on and on about the appetizers at a 4-star restaurant and then spending maybe a minute on the main course for a restaurant review.
Because, unlike Windows, OS-X, Lindows, and Red-Hat Slackware HAS to be installed. It is good to know beforehand what the install asks for, so I can have all information ahead of time. It also is an issue that there is no standard install processes, so if I just blindly click/type through I may delete a harddrive or partition that I didn't intend to.
I'll address your two points separately. First, on preparedness, all installations ask pretty much the same things (even Windows!): Where do you want to install this (and lets you manage your partitions), what do you want to install (package selection, which is generally presented as a few simplified options and an "advanced" option that lets you do it all yourself), and what are some of your basic configuration settings (language, timezone, network settings if you're doing a network install). If you've never installed Linux before you may not know what to expect, but then you won't know what to expect from any distro. For everything else, the box or web site should give you recommend configurations (CPU so fast, this much RAM, that much disk space, "compatible" video card, sound card, etc).
Your second point on standardization also doesn't have a place in a review. I could maybe justify a sentence or two calling out if this distro uses a similar installation to another (ie, does a Debian-based distro use Debian's installer?), but beyond that it doesn't matter. If you're going to click through randomly, you deserve what you get. Otherwise, you're going to read the manual, read the docs on the web site, and generally pay attention to what you're doing while you're doing it, because you don't want to screw stuff up. Whether you're an old pro at installing Linux (I must ask -- what are you doing, spending all of your time installing Linux rather than using it?) or you're a wet-behind-the-ears newbie, I just don't see any value in spending so much time on installation in a review beyond, "Installation was a snap" or "Installation had a few hiccups, but the manual/web site/docs helped out" (because obviously you were able to get it installed if you're reviewing it).
In the case of Slackware, the install and initial configuration is about the only thing that is easily accomplished and can be narrated in a small article. When one tries to do something more interesting, such as adding state-of-the-art hardware, patching the kernel for low-latency, or turning a slack-box into a media center or audio workstation, the writeup will quickly degenerate into an exposition of thousands of manual build/configuration steps requiring arcane and esoteric knowledge of the entire system, which will frighten away all but the most capable or most foolish (that would be me).
Maybe we have differing definitions for "review". What you're describing is a howto. I don't want to read a review telling me how the author went about setting up Foo or Bar. I want to know a) was it difficult setting up Foo, b) did Foo work assuming you were able to set it up, and c) how well did Foo work. Don't tell me how to setup Foo. For that, I'll read the manual or find a Howto (it's certainly valid to provide an appendix or footnote with links to whatever resources you used, of course).
Caldera (now SCO) did the tetris game. Corel did the "4-click" installer.
Good catch. For some reason I was thinking it was Corel Linux 2.0 (Corel's Debian-based attempt at a distro) that did the tetris thing. At least I got the "C" part right, and that it was a distribution nobody used:)
Can somebody please explain why every single Linux review has to spend so much time on installation? Monday's post of a SuSE review spent a third of the article just on installation. Today's Slackware review spends half of the review on installation (actually a bit more than half if you cut out the conclusion that takes up a quarter of the last page). People, installation is a solved problem! SuSE and Redhat have had competent installers for nearly a decade. Even Debian is slowly getting into the act. When Corel first integrated a game of tetris while packages installed, installation was a done deal. What possible reason can there be to spend all of your time reviewing the installation process, rather than everything else? (and by "everything else", I mean the integration that a distribution brings -- how well are menus configured in your chosen desktop environment, does it have a good package installation story that keeps those menus up to date, does it provide you with recent and stable versions of popular software, etc)
Yes, I know that installation of Linux is critical since you can't easily go out and buy a PC with Linux pre-loaded. I get that. However, the installers for pretty much every distro are simple and clear enough that it doesn't take a genius to use them. Skim your chosen distro's installation manual and have a go at it. Just please stop wasting review space writing about the installation process! Here's a hint: If your review is too short when you leave out the installer part, maybe you don't need to be writing a review.
Like I said, we geeks at Slashdot have been fighting Microsoft's desire to dominate the industry with monopolistic tendencies for the past 2-3 decades.
I'm pretty sure Slashdot hasn't been around for 2-3 decades...
How many of us have coded Open Source applications that try to read in Microsoft files. It's not easy. Look at how long it took us to get OpenOffice.org able to read and write back *.doc files decently.
I take it you contributed work to OpenOffice.org's.doc loading support? Because otherwise you wouldn't use the word "us", right?
As if you need another example, look at XML. Microsoft wants their own XML. Get real.
WTF? XML is XML. Microsoft isn't trying to get you to use square brackets instead of angle brackets. Sure, they may define different schemas for different purposes, but a) so does everyone else, and b) the XML standard allows and encourages you to do so.
They'd own all of us if they could. Their goal is to show profit and that's it, they don't give 2 sh*ts about you my friend. They want to get you into their products and make you buy more and more from them.
Interestingly, the best way to get you to buy their stuff so they can show a profit is by making it into something you want to buy. Maybe it's only caring about the user by happenstance, but it still amounts to the same thing.
The XBOX 360 better let me use a standard Firewire/USB to browse files I have on other devices. Just what do you expect from a $500 piece of plastic and $70 game system?
Firewire won't be built-in, but USB will. As for browsing your files, that depends. See, the Xbox360 is trying to be a media center as well as a game machine. Thus, it may browse your image or music files, but don't expect it to know what to do with a.doc or a Linux executable. Also, this is a one-way connection. The Xbox360 can read data off of these devices, but it can't put data back on. Don't expect to be able to fill up your iPod with songs from your Xbox360.
And for the record, it's a $400 piece of plastic (or $300, if you buy the core system without a hard drive), and $60 games (except from Microsoft, who've said their games will continue to be in the $40-$50 range; it's only EA who has confirmed the $60 price point). As for what I would expect? How about the ability to play games? Anything else is just extra, since this is still a game system at its heart.
WTF do you think I'm carrying my lighter laptop bag? To get to and from work and side jobs as an IT consultant.
Your comment on what you carry implied you carried said bag every day. My comment on a laptop bag was that I carry it only occassionally, and I don't so much carry it as I do move it from my house to my car and then my car to my office. As such, it's not really a daily item, and thus was only mentioned in passing.
Instead of your one "good book" I've got 500, plus the textbooks and reference books required for work and school.
The books I need for work are at work. I don't need to carry 500 of them around with me, because I don't need them. I carry a book for pleasure reading, and I don't like to split my attention for that. Sure, you might have 50 different novels you can read at any given time, but I'd rather read them one at a time. Besides, high resolution my paper novel is easier to read and easier on the eyes than your low resolution LCD. You might want to start taking better care of your eyes...
So instead of your 10 lb laptop, 2 pound book and 2 pound bag I've tried to explain how to cut the weight in half or a third. This will save your back and the nerves in your shoulder compressed by straps on a typical backpack.
Try 6lb laptop,.5lb book (if even that -- I carry around paperbacks for convenience), and maybe 1lb bag. Now consider that the 7lb laptop + bag combination is maybe carried 2 days of the week if that, leaving me with a.5lb book to your 5lb bag of goodies. And my book can be carried in several ways (pocket, hand, not carried at all as I can live without a book if I must). No strap required.
BTW the flashlight, laptop and multitool were useful yesterday troubleshooting problems for a local business putting $300 in my pocket.
Good for you. I didn't realize Yoga teachers did troubleshooting work. On the other hand, I put $300+ in my pocket just by showing up for work and doing my job. And when I left work, I still had that $300+ and I didn't have to carry around a geek arsenal "just in case"!
AND I don't look like a total jackass wearing a leather coat in the summer! (another 5 or 10 pounds I'll point out).
At least I don't look like a total jackass wearing black socks with sandals in the summer (or wearing sandals at all to work, as they're simply unprofessional)! Not saying you do, but you sound like the type that would. As for wearing a leather jacket during the summer, there are a few things to keep in mind. First, my "summers" average out to maybe 75F, with about a week total of days > 80F. Second, the jacket helps keep the sun off, sothat I don't have to deal with nasty sunburns on my arms or shoulders. Third, it's a light jacket, weighing maybe a pound or two, and that weight is evenly distributed across my frame (being a jacket and all...). Given all of that, it's not uncomfortable to wear a leather jacket during the summer where I live (if I lived in a warmer climate I wouldn't do so, but I don't) and it allows me to have an extra couple of pockets for random "stuff" without having to carry a purse or wear cargo pants.
You can have your sanctimonious attititude and 25 pounds of extra crap Osty. I'll take my lightweight gear bag.
I love how your math skills work. Using your own (outrageously incorrect) weight estimates, 10lb laptop + 2lb book + 2lb bag + 5lb jacket = 25lbs... err, I mean 19lbs.
Of course, the real calculation is quite a bit different. ((.5lb book + 2lb coat) * 5 days per week + (6lb laptop + 1lb bag) * 2 days per week) / 5 days per week = 5.3lbs avg carry weight per day of the week, rivaling your supposed 5.5lb bag. I guess the education required to land that job as alpha geek / yoga teacher didn't really cover mathematics all that well, huh? (How's that for sanctimonious?)
Oh. And the reference to "Yoga instructor" that flew over your head was that good ones study human anatomy.
Uh, yeah, flew right over my head. Then again, I might have been commenting on the fact that there's no way a yoga instructor needs to carry around all of the crap you mentioned. As you called yourself an "alpha geek[1] / yoga teacher", one can only assume that your occupation is "yoga teacher". But yeah, I could see how that could go over your head, thus making you think that the "yoga teacher" reference you made went over mine. My bad.
[1]: "Alpha geek" is not an occupation. For the record, if you have to call yourself an "alpha geek", chances are you're probably not, regardless of how much crap you carry around.
Rather than purge your bag, why not really lighten your load by not carrying around so much crap? What I carry on my person on a normal day:
Wallet with cash, ID cards, and credit cards. I'm partial to smaller tri-fold style wallets. Sits in my back pocket, and I feel naked without it.
Keys and pocket change. And by "keys", I mean "three keys", not some big huge ring of 50 different keys you'll never use. One for my car, one for my truck, and one for my house. Nothing more.
Work badge. Because I constantly break the little zip thingies you use to hang it from a belt, I've taken to carrying it in a pocket instead. Usually wrapped by a couple hair bands (because I have longer hair).
Cell phone that doesn't have a color screen, doesn't take pictures, and doesn't send or receive email. If you can't call me, I don't want to hear from you.
Sunglasses.
Wristwatch. Analog, preferably without any special features at all, and with simple tick marks instead of numbers. My current watch is analog with tick marks and has a day/month display that I could live without. Lives on my wrist, not taking up valuable pocket space. Another one of those, "I feel naked without it," items.
A good book.
I wear a leather jacket year-round (a heavier one during colder months, a lighter one during warmer months), which has enough pockets to hold my cell and sunglasses. Depending on the size of the book I'm currently reading, it will also usually fit into a coat pocket. Wallet, keys, badge, and change go into various pant pockets. Every other month or so work will saddle me with a pager for a week, but that fits into a coat pocket as well. I refuse to carry around anything else. I do have a laptop bag to take my laptop to and from work, but that's house to car to office and back.
At the very minimum, I can safely leave the house with nothing more than my wallet, wristwatch, and keys, and be completely happy and productive.
I see no need to carry around everything you listed. You don't need a flashlight, earplugs, headphones, etc. Maybe the life of a Yoga instructor is much more hectic than that of a software developer, but having not been a Yoga instructor I couldn't really say. I'd suspect not...
I just can't stand it when they don't post whether it's a windows-based or a unix/linux-based implementation. I need to know whether I can indulge in schadenfreude or whether I have to make excuses.
What does it matter? You didn't write their IT system, you didn't write Windows, and you didn't write Linux. I suspect you're probably not even Australian. What stake do you have in it?
For the record, I didn't write their IT system, nor Windows, nor Linux, and I'm not Australian either.
A BAC isn't really something depends on an "algorithm".
The "algorithm" is a way to turn the bad science of breath alcohol content into a valid blood alcohol content level. That many states have redefined their limits for breath alcohol content doesn't make it any more valid scientifically.
That said, LIDAR's aren't *ridiculously* inaccurate - if they read a speed, it's almost certainly going to be correct to within +/- ~10km/h. So if you get pinged doing 150km/h in a 100km/h zone, trying to use the inherent innacuracy of the LIDAR equipment as an excuse is pretty questionable (although it may well work, legally speaking).
It's not the ridiculous readings that will get you in trouble. The really high numbers will be laughed out of evidence ("Look, my F250 diesel can't possibly do 90mph!"). It's the 5mph and 10mph errors that are going to get you the ticket. Don't believe cops pull people over on a 5mph difference? I just saw it happen a couple days ago on my drive to work. I was doing about 36mph in a 35mph zone when my radar detector's laser warning went off. At the same time, I was being slowly passed by a car going mabye 40mph. The cop pulled out and tagged him. So there's a pretty good scenario where perhaps the LIDAR gun read my car first and then the passing car, which caused a > 5mph over the limit reading. Even if everything was kosher, if LIDAR is +/- 5mph then the cop shouldn't have pulled that guy over.
But it is. The data might not be 100%, but the algorithm is fine. Determining an object's velocity given it's displacement over a known timeframe is a pretty well-tested algorithm:).
Yes, I know "d = r * t" has been well tested and verified. The algorithm itself isn't wrong in this case. It's the application of the algorithm that's the problem. You're measuring multiple distances over a fixed set of time and inferring a velocity, yet you can't be 100% sure that you've measured the correct distances in that time span (I'm sure the distances are technically correct, but it's the end point that's in question).
Because blood tests are hard to automate and administer quickly (and in some jurisdictions might not be doable by an officer on the side of the road for legal reasons)[0], because LIDARs are more accurate, less error-prone and less avoidable than RADARs (hence the reason LIDAR replaced RADAR) and because pacing with a calibrated speedo implies significant possibility for human error, not to mention vastly cutting down on the number of vehicles than can be checked per hour.
Wah wah wah. So blood tests can't be automated and quickly administered. That's not an excuse to rely on flawed methodology. If you can't trust your evidence collection methods, too damn bad for you. And to be clear, I'm referring to borderline cases. You blow a 0.09, I'd say that's within the bounds of error for a breath machine. You blow a.13 and you're well and truly screwed. It's possible that the machine could err that badly, but not likely. It's not only possible, but likely for the machine to err.01-.02% (turning a legal.07 into an illegal.09). If the cops can't afford to "waste" time running suspects over to the local hospital for a blood test, then something's wrong with the system. And the fix is not to redefine everything in terms of breath alcohol content so you can rely on faulty breath machines. The strong odor of alcohol and the driver's behavior should be enough to give suspicion. If it's not, too bad, the cop screwed up.
LIDAR has its own set of problems, including that it must be used from a stationary position (which many cops violate, as I've witnessed first hand). RADAR units can be used while in movement, because they're not measuring distance. As well
That said, wouldn't releasing the code also involve the algorithm?
Yes, but successful implementation of a bad algorithm does not make the algorithm good. My concern is that these tools are based on flawed assumptions and bad science. My hope is that opening the source is just the first step in taking a closer look at a number of supposedly-infallible instruments with the intention of providing a fair defense for the accused. It probably won't happen, but analyzing the science behind the machine is the logical next step after analyzing the machine's implementation.
The larger problem here is that a lot of these tools (breathalyzers, RADAR and LIDAR guns, etc) are dealing with ambiguous data in the first place. For example, the algorithm used to determine BAC in a breathalyzer may be implemented correctly, but what if the algorithm itself is wrong? You're dealing with many variables (a person's mass, their metabolism, etc), and those variables have different values for different people. It's well-known, for example, that women will blow higher on a breathalyzer than a man simply because they're generally smaller.
Similarly for LIDAR (laser speed detection), the underlying principle is using distance and time to determine rate. Sounds straightforward, as d = r * t, but how do you know you've got the right values for d? It's been shown that rapid movement of a LIDAR gun can cause even inanimate objects to register a rate. How do we know the LIDAR gun measured the distance your car traveled over a period of time, rather than the distance of your car at one point in time and the distance of some other reflective object (say, a much closer stop sign) at a different point in time? At the distances in question, we're talking sharpshooter skills as a requirement for using a LIDAR gun, but it seems that every cop on the force has one. Can they expect us to believe that every cop is a sharpshooter, or that several cups of coffee won't induce shaking in the cop's hands that could cause false readings?
It's a good precedent, forcing the breathalyzer source to be opened to inspection, but the assumption is still that the underlying algorithm is accurate when it's not. I don't understand why courts continue to rely on technology such as the breathalyzer or the LIDAR gun when there are better, proven tests that could be used instead (blood tests, RADAR or pacing with a calibrated speedometer). Worse, once a court has chosen to allow such evidence (this is not arbitrary, but once the admissability of such a test is challenged and lost it's almost impossible to re-challenge), you can no longer argue that the underlying tool is bad (without extenuating circumstances that would bring the acceptability of such tools back into question). You can argue that the machine wasn't properly calibrated or maintained or that the officer using it was untrained or unqualified or out of practice, but you can't argue that the tool itself is inadmissable as evidence even if the facts are on your side.
* "Dead lines" are never really dead lines. They are just guidelines to when you should reach something that works (not works well). The management (or a good management) always takes into account you probably won't make it in time anyway.
That's not necessarily true. At least, not the way you explain it. Deadlines can be real "dead lines", in that if you miss the deadline you're dead (or your project, anyway). However, don't forget that time (deadlines) is just one part of a triumvirate of quality, time, and features. If time is fixed (you're on a contract with a specific end date, you've publicly promised to ship on a certain date, a different team has publicly promised to ship on a certain date and your project is a requirement for their shippnig, etc), then something else has to give. Enlightened managers will cut features in favor of quality. Unenlightened managers will cut quality in favor of features. The only way to deal with this as a front-line developer is to make sure you're getting pressure from only one place -- your direct manager. If your manager's manager is dictating something else, you have the right to tell him or her to go through your own manager (in a diplomatic sort of way, unless you like being on the shitlist). Of course, you can go the other way, too. If your manager is setting unrealistic goals, or is damaging the project (focusing on features instead of quality), you can and should go to their manager and discuss the problem. Either way, you can't perform two contradictory actions at the same time, so you need to speak up.
* Good design and code re-use are there to save time, not to waste it. Take the time doing things right, and it will save you time in the long run.
You must not work in the commercial world. Looming deadlines and a list of promised features often means you have to sacrifice some quality. Usually you'll do so with the intention of cleaning it up in V.Next, but the vicious cycle of less time and more features conspires against you. The best you can do is argue in favor of doing things right, or at least taking some time to do a postmortem to evaluate why quality had to be cut and try to get time to clean things up. That's a problem with shrink-wrapped software, though, because nobody's going to buy a new version just because you cleaned up the architecture (assuming the previous version works well enough already). So you're back into doing features rather than fixing brokenness. While it sucks, you can at least take some solace in knowing that you wanted to do the right thing but couldn't because of someone higher up the chain.
* You should always please whoever controls your future (but first, yourself).
In the broadest sense, you control your future. But more pragmatically, it's really difficult serving two masters. You'll be happier and better serve your career growth by using the chain of command to work for you. Make sure you're only taking tasks from your direct manager, and don't accept any tasks that didn't come down that chain. There are times when you can and even should take tasks from people other than your manager, but when crunch time is on and it's a Do or Die situation, funnel those requests.
Finally, evaluate why there's no time to do things right. Are you giving bad estimates? Are your estimates being changed by others besides you (people who aren't going to do the work)? Are your estimates assuming a perfect working environment? (if so, adjust your estimate to include context switching time to deal with interruptions, or lobby for "dark days" where you can turn off email, shut your door, and stop any interruptions so you can get a full day's work done.) Maybe you can change some things. Maybe you need to change your own view. Maybe you need to change jobs.
The parent erred. The post ment to suggest Fyodor Dostoevsky was possibly the second greatest novelist of all time. This, of course, is also an error, as Miguel de Cervantes was the greatest novelist of all time, followed by Tolstoy, then by Flaubert.
Or, he was referring to Monkey Island's running gag of, "That's the second biggest [monkey head | duck | arrow | etc] I've ever seen."
Is it so wrong that Monkey Island was the first thing that came to mind when reading the OP's post?
Slashdot Mirror
Looks like we have a definition of terms problem. Most of what you mentioned is what you previously called "Application logic". My question was whether or not you really meant "Application logic" or "Business logic", where "Business logic" is "actions applied to your data" and "Application logic" is "actions using your data" (yes, "Business logic" isn't really a good name for this, but it's what we've got). The only piece of business logic in what you mentioned is the insert into the database. In this case, it's extremely trivial business logic, but it's still business logic. As such, I'd say it merits a stored procedure, for the obvious reasons (you may have some logic around how you insert into the database, including relations and such) and the not so obvious reasons (stored procedures, when implemented and called correctly, protect against SQL injection attacks, increase performance, abstract your data layer by providing a consistent interface even when the underlying structure may change, keep your data logic close to the data, allow you to make updates to said logic without affecting your client apps, and simplify permissions by allowing you to grant EXECUTE access to only the procedures needed by an app rather than figuring our your SELECT, INSERT, UPDATE, and DELETE permission chains).
Then you got ripped off. A database engine can be much more than an alternative file system. Maybe you don't really have any complex data needs, but that doesn't negate the ability of a database engine to do real work.
"Stored procedures" written in C# should really be thought of in the same way as the extended procedures from SQL Server 2000. In otherwords, you probably will never use that feature, and if you do find that you need it you must really scrutinize why and the security implications of doing so. In most cases, you're better off with straight T-SQL procedures, and that hasn't changed for SQL Server 2005.
Personally, I haven't yet found a good reason to use C# stored procedures, but I'm also not using SQL Server 2005 yet. When my team migrates in the coming months, I might change my tune, but for now I'm more interested in other feature enhancements like try/catch error handling semantics and the snapshot isolation levels (allows for better concurrency without having to risk dirty reads by using (nolock) or setting a "read uncommitted" isolation level).
Do you have examples of procedures gone horribly wrong? Preferably not something completely obvious, like a proc that takes a varchar(8000) as input and just passes that to exec (completely stupid, negates all of the benefits of using stored procs). From my experience, you're better off using stored procedures than dynamic SQL in your code, so long as a few sanity check requirements are in place -- limit the amount of dynamic SQL in your procedures, prefer table variables over temp tables (to prevent recompilations), and general T-SQL best practices: limit your use of cursors and looping since SQL is a set-based language, keep your transactions as short as possible, avoid forcing index hints, count() on an indexed column or better yet * (allows the plan engine to pick the best column to count on), etc.
Depends on what you mean by "application logic". If you meant to say "business logic", then I must vehemently disagree -- business logic should live close to the data, in a reusable form so it need not be implemented in each app that wants to use the data. Ideally that means stored procedures. If you can't implement your business logic in T-SQL, then you need to re-think your logic requirements and your schema. If it still can't be done, then you can go ahead and start moving it into external libraries, but you should try your best to keep your logic as close to your data as possible.
Just because Konfabulator starts with a 'K' doesn't mean it's a KDE tool. In fact, it doesn't even run on Linux, but Windows and Mac OS X. Oh yeah, and it's owned by Yahoo now, too. Looks like gadgets, widgets, and sidebars are the new battelground, with Yahoo, Apple, Microsoft, and now Google in the mix. Yahoo has a serious lead, since Konfabulator is the oldest product.
Please?
For what it's worth, Live.com (and Start.com before it) uses Atlas. Building Gadgets for Live.com/Start.com is a good way to get your feet wet with Atlas, though they could do a better job of providing documentation.
Alternatively, Microsoft is in the same position as they were a decade ago, with Google now playing the role of Netscape. We all know how that ended.
Most likely you're thinking about NetDocs, which, though it never shipped as a single product, did actually contribute many pieces to Office (InfoPath in particular), MSN (parts of their billing and support system, Messenger, pieces of MSN Explorer), and other Microsoft products that did ship. Alternatively, you might have seen pieces of Hailstorm, which was later named ".NET My Services" before being killed. Again, much of Hailstorm's knowledge made its way into .NET (Hailstorm was all about Web Services right when the whole .NET thing was starting up, and it's no coincidence that .NET has very robust support for SOAP-based web services).
This is not all that different from what other companies do, with the exception of Microsoft publicizing projects that are eventually killed or integrated into something else. This is not even unusual for Microsoft. For example, where do you think the Office Assistant (Microsoft Agent) stuff came from? Microsoft Bob (especially the dog and cat). While it was patronizing and simplistic, it was also way ahead of its time -- task-based interface, scaleable vector graphics, "interactive" help (say what you will about Clippy and the Office Assistant crap, but many people liked them and you can't really argue with the cuteness factor), etc. This is how companies grow and innovate. What Microsoft learned from Hailstorm surely has a direct effect on Windows Live, just as what they learned from NetDocs affected Office and what they learned from Bob affected Windows and Office. For example, they've learned to use open betas to their advantage, and to incubate fresh ideas with little intervention (Start.com, the origin of Live.com and arguably the cornerstone to the whole project, was developed, shipped, and supported by a team of only two or three developers with no management overhead or other BS, and who were allowed to be open about the process through blogging and customer interaction -- they were even allowed to support Firefox!).
People scoffed at the first couple versions of Internet Explorer, but when Microsoft got fired up they really blew everybody away. Hopefully this time they've learned that follow-through is just as important as shipping, and Windows Live doesn't stagnate the way IE did.
Have you even tried using Live.com? Sure, it's superficially like Google's personalized home page, but it does more than that. First off, Live.com is from the Start.com project, which has been around longer than Google's personal page (as others have already pointed out), and thus Google is copying Microsoft. BWAHAHAHA. Ahem. Second, Live.com is more "slick", for lack of a better word. You can change the number of columns (want 2 columns instead of 3? only 1 long column?), and the interface just feels "smoother" than Google's (not sure if it's the colors, fonts, icons, or what, and I'll agree that this is really personal preference).
Third, and probably most importantly, Live.com is much more customizable than Google's page. Sure, you can add or remove certain canned items or create a new "section" from a search or a feed on Google's page. You can do that on Live.com as well. However, you can also write your own "gadgets" to add on to the page that are not just RSS feeds. I'm sure Google has the knowledge and talent to be able to do something like that, but you can't deny that Live.com does things Google Personal doesn't.
As for the name "Windows Live", the Slashdot article title is just completely stupid. This is not an "Internet Version of Windows", but a companion. The "Live" naming obviously comes from Xbox Live, which is not an "Internet Version of Xbox" but a companion service that allows you to communicate and interact in new and interesting ways with your Xbox ("new" and "interesting" as applied to Xbox, as online gaming, voice chat, and friends lists have all obviously been done elsewhere before Xbox Live). "Windows Live" is obviously aiming at that same idea. Whether they get there or not is still yet to be seen, but at least they're trying. That the beginning looks like stuff we've already seen (though to be fair, we did see it from Microsoft before Google) isn't the point. Go to Windows Live Ideas and look at some of the stuff that's coming. Live Mail is just parity, but Windows Live Safety Center looks pretty cool, as does Windows Live Favorites (okay, so it only imports from IE and not Firefox, but a) it is Beta, and b) it is still Microsoft ...). And it sounds like this is just the beginning. Maybe the whole Windows Live thing will fizzle out with nothing more than a neat portal and a modern web mail client, but it could also turn into something really cool.
We've had good results using Sharepoint (hey, you said you were using Microsoft products) to track documents, schedules, tasks, todo lists, etc. It's not as robust as a full source control system like Subversion, but it works well for management stuff (bonus: it's all web-based, so you don't need a local client or enlistment). For binary files like Word or Project files, you really need a method of locking the file. SVN and CVS are really geared towards concurrent changes in text files that are mergeable, so they're not so great for binaries.
Sharepoint is also really useful for lists. In fact we tracked our last release entirely through Sharepoint, from building task lists to release schedules, tracking bug counts and resolution rates, etc. I'm sure there are other solutions out there besides Sharepoint, but Sharepoint is what I have experienced. For example, it shouldn't be difficult to find or write a web interface to Subversion or CVS that will eliminate the need for managers to run enlistment updates just to make sure they have the latest version of a doc. Of course developers should continue to have local enlistments, as they're more efficient that way.
First off, only EA has said they'll be pricing games at $60. In fact, Microsoft has said that all of their 360 launch titles will be at $50 or less ($60 for the two-disk PDZ collector's edition). One could extrapolate that future Microsoft titles will be $50 or less, too, but I won't go there.
Second, there's always talk of selling stupid crap like textures or weapons or whatever via Live. It happened with Xbox Live a couple of years ago, and it's happening now with the 360 revision. That doesn't mean it will happen. So far, premium content on Live has been truly "extra" stuff. New maps in Halo 2 (which, BTW, were eventually released for free as well), new cars and tracks in PGR2, etc. And they weren't "one map/car/track at $5", either, but a bundle of several maps, several cars and tracks at $5. Points will allow for micropayment-like transactions so that you could theoretically buy one of the cars for $0.25 instead of all 9 for $5.
Finally, please keep in mind that while Live is a big selling point, the 360 (as the Xbox before it) still needs to be accessible to people without broadband (even though Live Silver is free and comes with every 360, you still may not have the required broadband). Thus, you're not going to buy just a game engine for $60 and be nickled and dimed trying to buy all of the models, textures, and maps needed to make a full game. As well, Microsoft doesn't allow developers to charge for patches that fix problems, so you're not going to see a case where you buy a $60 game and then have to spend another $5 for a bunch of bug fixes.
Be paranoid all you like, but it helps to actually understand what you're scared about first.
So what? That doesn't belong in a review. It belongs in a howto or manual. And please note that I have nothing against a sentence or two, maybe even a paragraph discussing installation. What I'm arguing against is spending 50%+ of a review covering installation. That's just silly. Most people will eventually be able to get the OS installed, at which point they want to know how the rest of the system works. Focusing on installation is like raving on and on about the appetizers at a 4-star restaurant and then spending maybe a minute on the main course for a restaurant review.
I'll address your two points separately. First, on preparedness, all installations ask pretty much the same things (even Windows!): Where do you want to install this (and lets you manage your partitions), what do you want to install (package selection, which is generally presented as a few simplified options and an "advanced" option that lets you do it all yourself), and what are some of your basic configuration settings (language, timezone, network settings if you're doing a network install). If you've never installed Linux before you may not know what to expect, but then you won't know what to expect from any distro. For everything else, the box or web site should give you recommend configurations (CPU so fast, this much RAM, that much disk space, "compatible" video card, sound card, etc).
Your second point on standardization also doesn't have a place in a review. I could maybe justify a sentence or two calling out if this distro uses a similar installation to another (ie, does a Debian-based distro use Debian's installer?), but beyond that it doesn't matter. If you're going to click through randomly, you deserve what you get. Otherwise, you're going to read the manual, read the docs on the web site, and generally pay attention to what you're doing while you're doing it, because you don't want to screw stuff up. Whether you're an old pro at installing Linux (I must ask -- what are you doing, spending all of your time installing Linux rather than using it?) or you're a wet-behind-the-ears newbie, I just don't see any value in spending so much time on installation in a review beyond, "Installation was a snap" or "Installation had a few hiccups, but the manual/web site/docs helped out" (because obviously you were able to get it installed if you're reviewing it).
Maybe we have differing definitions for "review". What you're describing is a howto. I don't want to read a review telling me how the author went about setting up Foo or Bar. I want to know a) was it difficult setting up Foo, b) did Foo work assuming you were able to set it up, and c) how well did Foo work. Don't tell me how to setup Foo. For that, I'll read the manual or find a Howto (it's certainly valid to provide an appendix or footnote with links to whatever resources you used, of course).
Good catch. For some reason I was thinking it was Corel Linux 2.0 (Corel's Debian-based attempt at a distro) that did the tetris thing. At least I got the "C" part right, and that it was a distribution nobody used :)
Can somebody please explain why every single Linux review has to spend so much time on installation? Monday's post of a SuSE review spent a third of the article just on installation. Today's Slackware review spends half of the review on installation (actually a bit more than half if you cut out the conclusion that takes up a quarter of the last page). People, installation is a solved problem! SuSE and Redhat have had competent installers for nearly a decade. Even Debian is slowly getting into the act. When Corel first integrated a game of tetris while packages installed, installation was a done deal. What possible reason can there be to spend all of your time reviewing the installation process, rather than everything else? (and by "everything else", I mean the integration that a distribution brings -- how well are menus configured in your chosen desktop environment, does it have a good package installation story that keeps those menus up to date, does it provide you with recent and stable versions of popular software, etc)
Yes, I know that installation of Linux is critical since you can't easily go out and buy a PC with Linux pre-loaded. I get that. However, the installers for pretty much every distro are simple and clear enough that it doesn't take a genius to use them. Skim your chosen distro's installation manual and have a go at it. Just please stop wasting review space writing about the installation process! Here's a hint: If your review is too short when you leave out the installer part, maybe you don't need to be writing a review.
I'm pretty sure Slashdot hasn't been around for 2-3 decades ...
I take it you contributed work to OpenOffice.org's .doc loading support? Because otherwise you wouldn't use the word "us", right?
WTF? XML is XML. Microsoft isn't trying to get you to use square brackets instead of angle brackets. Sure, they may define different schemas for different purposes, but a) so does everyone else, and b) the XML standard allows and encourages you to do so.
Interestingly, the best way to get you to buy their stuff so they can show a profit is by making it into something you want to buy. Maybe it's only caring about the user by happenstance, but it still amounts to the same thing.
Firewire won't be built-in, but USB will. As for browsing your files, that depends. See, the Xbox360 is trying to be a media center as well as a game machine. Thus, it may browse your image or music files, but don't expect it to know what to do with a .doc or a Linux executable. Also, this is a one-way connection. The Xbox360 can read data off of these devices, but it can't put data back on. Don't expect to be able to fill up your iPod with songs from your Xbox360.
And for the record, it's a $400 piece of plastic (or $300, if you buy the core system without a hard drive), and $60 games (except from Microsoft, who've said their games will continue to be in the $40-$50 range; it's only EA who has confirmed the $60 price point). As for what I would expect? How about the ability to play games? Anything else is just extra, since this is still a game system at its heart.
Then again, I'm sure I've just been trolled.
Your comment on what you carry implied you carried said bag every day. My comment on a laptop bag was that I carry it only occassionally, and I don't so much carry it as I do move it from my house to my car and then my car to my office. As such, it's not really a daily item, and thus was only mentioned in passing.
The books I need for work are at work. I don't need to carry 500 of them around with me, because I don't need them. I carry a book for pleasure reading, and I don't like to split my attention for that. Sure, you might have 50 different novels you can read at any given time, but I'd rather read them one at a time. Besides, high resolution my paper novel is easier to read and easier on the eyes than your low resolution LCD. You might want to start taking better care of your eyes ...
Try 6lb laptop, .5lb book (if even that -- I carry around paperbacks for convenience), and maybe 1lb bag. Now consider that the 7lb laptop + bag combination is maybe carried 2 days of the week if that, leaving me with a .5lb book to your 5lb bag of goodies. And my book can be carried in several ways (pocket, hand, not carried at all as I can live without a book if I must). No strap required.
Good for you. I didn't realize Yoga teachers did troubleshooting work. On the other hand, I put $300+ in my pocket just by showing up for work and doing my job. And when I left work, I still had that $300+ and I didn't have to carry around a geek arsenal "just in case"!
At least I don't look like a total jackass wearing black socks with sandals in the summer (or wearing sandals at all to work, as they're simply unprofessional)! Not saying you do, but you sound like the type that would. As for wearing a leather jacket during the summer, there are a few things to keep in mind. First, my "summers" average out to maybe 75F, with about a week total of days > 80F. Second, the jacket helps keep the sun off, sothat I don't have to deal with nasty sunburns on my arms or shoulders. Third, it's a light jacket, weighing maybe a pound or two, and that weight is evenly distributed across my frame (being a jacket and all ...). Given all of that, it's not uncomfortable to wear a leather jacket during the summer where I live (if I lived in a warmer climate I wouldn't do so, but I don't) and it allows me to have an extra couple of pockets for random "stuff" without having to carry a purse or wear cargo pants.
I love how your math skills work. Using your own (outrageously incorrect) weight estimates, 10lb laptop + 2lb book + 2lb bag + 5lb jacket = 25lbs ... err, I mean 19lbs.
Of course, the real calculation is quite a bit different. ((.5lb book + 2lb coat) * 5 days per week + (6lb laptop + 1lb bag) * 2 days per week) / 5 days per week = 5.3lbs avg carry weight per day of the week, rivaling your supposed 5.5lb bag. I guess the education required to land that job as alpha geek / yoga teacher didn't really cover mathematics all that well, huh? (How's that for sanctimonious?)
Uh, yeah, flew right over my head. Then again, I might have been commenting on the fact that there's no way a yoga instructor needs to carry around all of the crap you mentioned. As you called yourself an "alpha geek[1] / yoga teacher", one can only assume that your occupation is "yoga teacher". But yeah, I could see how that could go over your head, thus making you think that the "yoga teacher" reference you made went over mine. My bad.
[1]: "Alpha geek" is not an occupation. For the record, if you have to call yourself an "alpha geek", chances are you're probably not, regardless of how much crap you carry around.
Rather than purge your bag, why not really lighten your load by not carrying around so much crap? What I carry on my person on a normal day:
I wear a leather jacket year-round (a heavier one during colder months, a lighter one during warmer months), which has enough pockets to hold my cell and sunglasses. Depending on the size of the book I'm currently reading, it will also usually fit into a coat pocket. Wallet, keys, badge, and change go into various pant pockets. Every other month or so work will saddle me with a pager for a week, but that fits into a coat pocket as well. I refuse to carry around anything else. I do have a laptop bag to take my laptop to and from work, but that's house to car to office and back.
At the very minimum, I can safely leave the house with nothing more than my wallet, wristwatch, and keys, and be completely happy and productive.
I see no need to carry around everything you listed. You don't need a flashlight, earplugs, headphones, etc. Maybe the life of a Yoga instructor is much more hectic than that of a software developer, but having not been a Yoga instructor I couldn't really say. I'd suspect not ...
What does it matter? You didn't write their IT system, you didn't write Windows, and you didn't write Linux. I suspect you're probably not even Australian. What stake do you have in it?
For the record, I didn't write their IT system, nor Windows, nor Linux, and I'm not Australian either.
The "algorithm" is a way to turn the bad science of breath alcohol content into a valid blood alcohol content level. That many states have redefined their limits for breath alcohol content doesn't make it any more valid scientifically.
It's not the ridiculous readings that will get you in trouble. The really high numbers will be laughed out of evidence ("Look, my F250 diesel can't possibly do 90mph!"). It's the 5mph and 10mph errors that are going to get you the ticket. Don't believe cops pull people over on a 5mph difference? I just saw it happen a couple days ago on my drive to work. I was doing about 36mph in a 35mph zone when my radar detector's laser warning went off. At the same time, I was being slowly passed by a car going mabye 40mph. The cop pulled out and tagged him. So there's a pretty good scenario where perhaps the LIDAR gun read my car first and then the passing car, which caused a > 5mph over the limit reading. Even if everything was kosher, if LIDAR is +/- 5mph then the cop shouldn't have pulled that guy over.
Yes, I know "d = r * t" has been well tested and verified. The algorithm itself isn't wrong in this case. It's the application of the algorithm that's the problem. You're measuring multiple distances over a fixed set of time and inferring a velocity, yet you can't be 100% sure that you've measured the correct distances in that time span (I'm sure the distances are technically correct, but it's the end point that's in question).
Wah wah wah. So blood tests can't be automated and quickly administered. That's not an excuse to rely on flawed methodology. If you can't trust your evidence collection methods, too damn bad for you. And to be clear, I'm referring to borderline cases. You blow a 0.09, I'd say that's within the bounds of error for a breath machine. You blow a .13 and you're well and truly screwed. It's possible that the machine could err that badly, but not likely. It's not only possible, but likely for the machine to err .01-.02% (turning a legal .07 into an illegal .09). If the cops can't afford to "waste" time running suspects over to the local hospital for a blood test, then something's wrong with the system. And the fix is not to redefine everything in terms of breath alcohol content so you can rely on faulty breath machines. The strong odor of alcohol and the driver's behavior should be enough to give suspicion. If it's not, too bad, the cop screwed up.
LIDAR has its own set of problems, including that it must be used from a stationary position (which many cops violate, as I've witnessed first hand). RADAR units can be used while in movement, because they're not measuring distance. As well
Yes, but successful implementation of a bad algorithm does not make the algorithm good. My concern is that these tools are based on flawed assumptions and bad science. My hope is that opening the source is just the first step in taking a closer look at a number of supposedly-infallible instruments with the intention of providing a fair defense for the accused. It probably won't happen, but analyzing the science behind the machine is the logical next step after analyzing the machine's implementation.
The larger problem here is that a lot of these tools (breathalyzers, RADAR and LIDAR guns, etc) are dealing with ambiguous data in the first place. For example, the algorithm used to determine BAC in a breathalyzer may be implemented correctly, but what if the algorithm itself is wrong? You're dealing with many variables (a person's mass, their metabolism, etc), and those variables have different values for different people. It's well-known, for example, that women will blow higher on a breathalyzer than a man simply because they're generally smaller.
Similarly for LIDAR (laser speed detection), the underlying principle is using distance and time to determine rate. Sounds straightforward, as d = r * t, but how do you know you've got the right values for d? It's been shown that rapid movement of a LIDAR gun can cause even inanimate objects to register a rate. How do we know the LIDAR gun measured the distance your car traveled over a period of time, rather than the distance of your car at one point in time and the distance of some other reflective object (say, a much closer stop sign) at a different point in time? At the distances in question, we're talking sharpshooter skills as a requirement for using a LIDAR gun, but it seems that every cop on the force has one. Can they expect us to believe that every cop is a sharpshooter, or that several cups of coffee won't induce shaking in the cop's hands that could cause false readings?
It's a good precedent, forcing the breathalyzer source to be opened to inspection, but the assumption is still that the underlying algorithm is accurate when it's not. I don't understand why courts continue to rely on technology such as the breathalyzer or the LIDAR gun when there are better, proven tests that could be used instead (blood tests, RADAR or pacing with a calibrated speedometer). Worse, once a court has chosen to allow such evidence (this is not arbitrary, but once the admissability of such a test is challenged and lost it's almost impossible to re-challenge), you can no longer argue that the underlying tool is bad (without extenuating circumstances that would bring the acceptability of such tools back into question). You can argue that the machine wasn't properly calibrated or maintained or that the officer using it was untrained or unqualified or out of practice, but you can't argue that the tool itself is inadmissable as evidence even if the facts are on your side.
That's not necessarily true. At least, not the way you explain it. Deadlines can be real "dead lines", in that if you miss the deadline you're dead (or your project, anyway). However, don't forget that time (deadlines) is just one part of a triumvirate of quality, time, and features. If time is fixed (you're on a contract with a specific end date, you've publicly promised to ship on a certain date, a different team has publicly promised to ship on a certain date and your project is a requirement for their shippnig, etc), then something else has to give. Enlightened managers will cut features in favor of quality. Unenlightened managers will cut quality in favor of features. The only way to deal with this as a front-line developer is to make sure you're getting pressure from only one place -- your direct manager. If your manager's manager is dictating something else, you have the right to tell him or her to go through your own manager (in a diplomatic sort of way, unless you like being on the shitlist). Of course, you can go the other way, too. If your manager is setting unrealistic goals, or is damaging the project (focusing on features instead of quality), you can and should go to their manager and discuss the problem. Either way, you can't perform two contradictory actions at the same time, so you need to speak up.
You must not work in the commercial world. Looming deadlines and a list of promised features often means you have to sacrifice some quality. Usually you'll do so with the intention of cleaning it up in V.Next, but the vicious cycle of less time and more features conspires against you. The best you can do is argue in favor of doing things right, or at least taking some time to do a postmortem to evaluate why quality had to be cut and try to get time to clean things up. That's a problem with shrink-wrapped software, though, because nobody's going to buy a new version just because you cleaned up the architecture (assuming the previous version works well enough already). So you're back into doing features rather than fixing brokenness. While it sucks, you can at least take some solace in knowing that you wanted to do the right thing but couldn't because of someone higher up the chain.
In the broadest sense, you control your future. But more pragmatically, it's really difficult serving two masters. You'll be happier and better serve your career growth by using the chain of command to work for you. Make sure you're only taking tasks from your direct manager, and don't accept any tasks that didn't come down that chain. There are times when you can and even should take tasks from people other than your manager, but when crunch time is on and it's a Do or Die situation, funnel those requests.
Finally, evaluate why there's no time to do things right. Are you giving bad estimates? Are your estimates being changed by others besides you (people who aren't going to do the work)? Are your estimates assuming a perfect working environment? (if so, adjust your estimate to include context switching time to deal with interruptions, or lobby for "dark days" where you can turn off email, shut your door, and stop any interruptions so you can get a full day's work done.) Maybe you can change some things. Maybe you need to change your own view. Maybe you need to change jobs.
Or, he was referring to Monkey Island's running gag of, "That's the second biggest [monkey head | duck | arrow | etc] I've ever seen."
Is it so wrong that Monkey Island was the first thing that came to mind when reading the OP's post?