After a lot of thought and meditation I have decided that it is time for a change. This change has been in the works for a long time. I want to belong to something monolithic and proprietary, and I think that .NET on Windows is the way to go.
The .NET platform empowers me with the ability to choose from a host of languages like C#, asp.NET, vb.NET, Boo, IronPython, IronRuby, and many more. And after long and careful consideration I have decided that my next language of choice will be C#.
C# is under the stalwart auspices of Microsoft itself, instead of some guy from Denmark. It has static typing and thanks to compilation most bugs are caught quickly. The curly braces clearly delineate code blocks, and the semi-colons show me when a statement ends. Partial classes will let me spread my object code across many files, and lambda expressions will let me compress complicated functionality into generic functions. Documentation is done via XML rather than the RestructuredText used across the Python community.
Of course, Visual Studio has a lot of visual elements. I am not sure what that means, but being Visual is obviously superior to the TextMates and EMACS I have used in the past. I can't afford Visual Studio yet, but if I don't buy any groceries for myself, wife, and son, I should be able to pay for my copy in only 2-4 months!
In summary this year looks very exciting.
Update: This was an April Fool's joke.
Showing posts with label technology. Show all posts
Showing posts with label technology. Show all posts
Tuesday, March 31, 2009
Monday, October 20, 2008
Normalization, Non-Normalization, Denormalization
I don't do much SQL anymore, thanks to tools like SQL Alchemy and the rather proprietary and object oriented ZODB. However, when I do interact with SQL databases I always go for the 5th normal form because this just seems right. I've dealt with more than enough non-normalized databases in my time to feel completely justified in this response to bad design.
The worst cases of non-normalized data in my experience have been with financial transactions or user data. Once I dealt with a financial databases that tracked the amounts in a pool of money in the same table as the historical transactions against that pool. Sound confusing? You bet, especially since determining what money was real and what was historic was done in an amazing piece of undocumented spaghetti code.
I've admittedly created two monsters of this sort of design. One was my first database design in a professional environment, and as the project went on I realized my mistakes and tried to fix them. The other was a database design where I took an application running by itself and tried to create an environment for it where multiple people could have instances of this application. It worked, but it was really hacked. I didn't know about source control back then so going back to doing it right was impossible.
So now you understand why I like normalized databases. Of course, once I get something working in 5th normal form then I start considering breaking the rules. And I do so in a systematic approach. This is called denormalization. The art of denormalization is knowing when to break the rules of normalization to improve performance and make life easier for anyone touching the project. The key is that when you do this that your breakage is clearly identified in developer documentation.
Some places I've found are good for denormalization include financial transactions, report helpers, and tables that track the history of another record.
Its shocking though how often I've run into people who equate non-normalized databases with denormalized databases. Sometimes you get a few newbies who like the sound of 'denormalization' as a word, but normally in my experience it is due to some 'senior developer' who hasn't read a coding book since 1997. You know who I am talking about.
The worst cases of non-normalized data in my experience have been with financial transactions or user data. Once I dealt with a financial databases that tracked the amounts in a pool of money in the same table as the historical transactions against that pool. Sound confusing? You bet, especially since determining what money was real and what was historic was done in an amazing piece of undocumented spaghetti code.
I've admittedly created two monsters of this sort of design. One was my first database design in a professional environment, and as the project went on I realized my mistakes and tried to fix them. The other was a database design where I took an application running by itself and tried to create an environment for it where multiple people could have instances of this application. It worked, but it was really hacked. I didn't know about source control back then so going back to doing it right was impossible.
So now you understand why I like normalized databases. Of course, once I get something working in 5th normal form then I start considering breaking the rules. And I do so in a systematic approach. This is called denormalization. The art of denormalization is knowing when to break the rules of normalization to improve performance and make life easier for anyone touching the project. The key is that when you do this that your breakage is clearly identified in developer documentation.
Some places I've found are good for denormalization include financial transactions, report helpers, and tables that track the history of another record.
Its shocking though how often I've run into people who equate non-normalized databases with denormalized databases. Sometimes you get a few newbies who like the sound of 'denormalization' as a word, but normally in my experience it is due to some 'senior developer' who hasn't read a coding book since 1997. You know who I am talking about.
Saturday, September 13, 2008
Best career technology choice I ever made besides learning python...
I refused to ever touch Crystal Reports. I became the ugly, ranty developer and yelled and screamed rather than touch Crystal Reports.
I don't even need to explain why this was such an awesome move on my part.
My life is so much better for it.
I don't even need to explain why this was such an awesome move on my part.
My life is so much better for it.
Tuesday, September 9, 2008
List of programming languages I know
Gakked from Corey Goldberg, here is what I've learned in the last odd 28 years of doing coding off-and-on, in the rough order that I learned them. Items are bold are languages in which I am current:
- Apple ][ Basic (1980)
- HTML (1995ish)
- Foxpro (1997)
- SQL (1997)
- WebML (1998)
- JavaScript (1998)
- ColdFusion (1999)
- Perl (1999)
- CSS (1999)
- Java (2000)
- Python (2005)
Monday, September 8, 2008
Don't bet on closed source third party software!
US Government Agency story
Sometime in the late 1990s a US government agency (NASA) made a decision to go with a certain set of form software. Basically, this software allowed a person to use a desktop application to easily generate complex government form with data fields. The ability to easily generate paper forms that could be effortlessly converted to PDF was allowed via Adobe Acrobat Professional. All was good.
Over the next few years hundreds, perhaps thousands of forms were generated this way. A few select staff of the agency became experts in creating these forms, or converting existing paper forms into this system. Changes required for whatever reason were easily and quickly implemented, and the forms reached a pinnacle of quality. All was good.
Then, in late 2004, the company that made agency's chosen form software was purchased out by a competitor. And the first thing the purchasing company did was to cancel the products of their competitor. You couldn't buy the forms product, nor could you get support. The product was dead.
At the agency's HQ, the person using the forms software left the agency for other things. The purchased copy/copies of the forms software was somehow lost. This meant that making any changes to agency HQ forms would require rebuilding forms from scratch. Since government forms are complex, you are talking about hundreds of hours of work, especially when stuck with limiting tools such as Microsoft Word, a tool not designed for this kind of work.
At this point I stopped paying attention because it was too depressing. My guess is that the agency fixed the problem with Microsoft Word, since it was already paid for, even though using it for this role is not very efficient. Or they might have a different solution, and I pray its something good, something in the open source arena, because then even if the project collapses, writing a migration system to pull your data out is a bit easier since you have access to the source code.
This sort of thing happens from time to time. People bet on close source third party software and it nails them hard. And sometimes they don't even realize its happening...
Democracy story
Let us imagine a powerful nation which decides to rid itself of paper or mechanical ballots and go modern and electronic. They pick a security firm to deliver computerized voting machines. The delivered voting machines were pretty much proven insecure and the tallying code was beyond review since it was compiled, patented, and closed. Electoral workers and security analysts both complained that since the code was closed, there was no way to ensure that election counts were accurately tallied.
Yes, I'm talking about Diebold in the United States.
Getting past the rather intimidating security issues, the issue of closed source tallying code is terrifying. How do we know that the systems can't be used for doctoring elections? Because Diebold says so? Even if everyone implicitly trusted Diebold, do we really want to bet our future on just one small group of hidden people when the whole country could be vetting their code?
Flashpaper Story
Until I moved to Mac OS X in 2007 I hated Adobe's Portable Document Format (PDF). It didn't seem very portable, the readers were slow, and just displaying it even in modern computers slow my machine down horrifically.
And yet, back in 2002 Blue Pacific released Flashprinter which Macromedia bought and released as Flashpaper. The beauty of it was that it was part of the Flash system, which meant that any browser that supported Flash (all of them I think) supported Flashpaper documents. It printed out nicely, displayed beautifully, was lighter than PDF, and tools were easy to write for it.
In December of 2005, Adobe bought out Macromedia. Amazingly, they didn't cancel Flashpaper right away. Nope, they waited until September of 2008 to cancel this competitor to PDF. Of course, most of us shied away from Flashpaper, since the writing was on the wall.
Not everyone shied away. Young internet startups specializing in documentation seem to have really focused on the technology. What the heck were they thinking? Didn't their Venture Capitalists (VC) examine the technology base at all? I'm hoping they have alternatives ready soon, but my guess is that at least one new venture is going to fail as a VC pulls out his money and rethinks how they do analysis of proposed efforts going forward.
Summary
This isn't to say that closed source is bad. Well, maybe it is bad.
As for me, when I have a choice I use Linux. I can get away with doing my code in open source text editors (although I do prefer the relatively inexpensive and superlative closed source Textmates on Mac OS X).
Note: On September 3rd, 2011 I updated this to state that the agency listed in the first section of this article was NASA.
Sometime in the late 1990s a US government agency (NASA) made a decision to go with a certain set of form software. Basically, this software allowed a person to use a desktop application to easily generate complex government form with data fields. The ability to easily generate paper forms that could be effortlessly converted to PDF was allowed via Adobe Acrobat Professional. All was good.
Over the next few years hundreds, perhaps thousands of forms were generated this way. A few select staff of the agency became experts in creating these forms, or converting existing paper forms into this system. Changes required for whatever reason were easily and quickly implemented, and the forms reached a pinnacle of quality. All was good.
Then, in late 2004, the company that made agency's chosen form software was purchased out by a competitor. And the first thing the purchasing company did was to cancel the products of their competitor. You couldn't buy the forms product, nor could you get support. The product was dead.
At the agency's HQ, the person using the forms software left the agency for other things. The purchased copy/copies of the forms software was somehow lost. This meant that making any changes to agency HQ forms would require rebuilding forms from scratch. Since government forms are complex, you are talking about hundreds of hours of work, especially when stuck with limiting tools such as Microsoft Word, a tool not designed for this kind of work.
At this point I stopped paying attention because it was too depressing. My guess is that the agency fixed the problem with Microsoft Word, since it was already paid for, even though using it for this role is not very efficient. Or they might have a different solution, and I pray its something good, something in the open source arena, because then even if the project collapses, writing a migration system to pull your data out is a bit easier since you have access to the source code.
This sort of thing happens from time to time. People bet on close source third party software and it nails them hard. And sometimes they don't even realize its happening...
Democracy story
Let us imagine a powerful nation which decides to rid itself of paper or mechanical ballots and go modern and electronic. They pick a security firm to deliver computerized voting machines. The delivered voting machines were pretty much proven insecure and the tallying code was beyond review since it was compiled, patented, and closed. Electoral workers and security analysts both complained that since the code was closed, there was no way to ensure that election counts were accurately tallied.
Yes, I'm talking about Diebold in the United States.
Getting past the rather intimidating security issues, the issue of closed source tallying code is terrifying. How do we know that the systems can't be used for doctoring elections? Because Diebold says so? Even if everyone implicitly trusted Diebold, do we really want to bet our future on just one small group of hidden people when the whole country could be vetting their code?
Flashpaper Story
Until I moved to Mac OS X in 2007 I hated Adobe's Portable Document Format (PDF). It didn't seem very portable, the readers were slow, and just displaying it even in modern computers slow my machine down horrifically.
And yet, back in 2002 Blue Pacific released Flashprinter which Macromedia bought and released as Flashpaper. The beauty of it was that it was part of the Flash system, which meant that any browser that supported Flash (all of them I think) supported Flashpaper documents. It printed out nicely, displayed beautifully, was lighter than PDF, and tools were easy to write for it.
In December of 2005, Adobe bought out Macromedia. Amazingly, they didn't cancel Flashpaper right away. Nope, they waited until September of 2008 to cancel this competitor to PDF. Of course, most of us shied away from Flashpaper, since the writing was on the wall.
Not everyone shied away. Young internet startups specializing in documentation seem to have really focused on the technology. What the heck were they thinking? Didn't their Venture Capitalists (VC) examine the technology base at all? I'm hoping they have alternatives ready soon, but my guess is that at least one new venture is going to fail as a VC pulls out his money and rethinks how they do analysis of proposed efforts going forward.
Summary
This isn't to say that closed source is bad. Well, maybe it is bad.
As for me, when I have a choice I use Linux. I can get away with doing my code in open source text editors (although I do prefer the relatively inexpensive and superlative closed source Textmates on Mac OS X).
Note: On September 3rd, 2011 I updated this to state that the agency listed in the first section of this article was NASA.
Thursday, June 5, 2008
MVC public service videos
The railsenvy guys do it again with a series of public service videos on model-view-controller. I especially like the third and fourth videos. Unlike their RoR versus videos, these are tool neutral.
http://railsenvy.com/2008/6/3/mvc-videos
http://railsenvy.com/2008/6/3/mvc-videos
Wednesday, February 6, 2008
Thursday, January 10, 2008
I concur
http://www.wired.com/politics/security/commentary/securitymatters/2008/01/securitymatters_0110
We let our neighbors, which include police officers and at least one employee of a federal law enforcement agency to use our wireless network.
We let our neighbors, which include police officers and at least one employee of a federal law enforcement agency to use our wireless network.
Wednesday, October 3, 2007
Interesting...
http://www.gamearchitect.net/Articles/SoftwareIsHard.html
Choice quote that worries me about counting lines of code:
Here is another interesting bit:
The closer thought is this line:
Better yet, lets ditch this series of fighter and just go to UAVs. Cheaper, better performance, and no pilot risk.
I'm so glad I don't work for DoD anymore.
Choice quote that worries me about counting lines of code:
"Speaking of lines of code, my friend Rebecca, who's a Pentagon reporter, has sat through countless briefings about military software projects. She's bemused at the briefer's fondness for citing the number of lines of code in the systems they're developing."Lean, mean code is better than big, bloated code. And using lines of code as a metric is something I thought went out of vogue a long time ago.
Here is another interesting bit:
Let's look back at the F-22. Why did it take dozens of software engineers working on the F-22 avionics code four times as long to produce 750,000 lines of code as it's taken the Fracture team? Is the average programmer at Day 1 Studios a hundred times as productive as the average programmer at Boeing? Of course not. The F-22's avionics suite is life-critical software. It has strong interdependencies on changing hardware.Life critical software is hard. Toss in the extra work developers have to do in a CMM-5 shop and things start to bulk up. Everything has to be explained and checked. On the other hand, often your code ends up looking pretty good since you get really smart people giving you peer reviews.
The closer thought is this line:
The hardware it runs on is nearly twenty years old now, which increases iteration times (the F-22 runs on a VAX/VMS system like the college mainframe when I started at Davidson, back in 1990)I'm not sure I'm happy or not at this statement. The F-22 costs us about $450 million dollars a plane so I'm happy that they've got super mature systems in place. On the other hand, wouldn't it be nice to see five hardened Linux pizza boxes in the place of the VAX mainframe?
Better yet, lets ditch this series of fighter and just go to UAVs. Cheaper, better performance, and no pilot risk.
I'm so glad I don't work for DoD anymore.
Subscribe to:
Posts (Atom)
