Gas Factory
Yo-yo problem
Spaghetti Code
Copy-and-paste programming
BaseBean
Dependency Hell
God Object
And of course:
Brooke's Law
This isn't a finger point post. We are all guilty of these things, and sometimes doing it is necessary for completion of a project, especially when you get stuck with the limitations of a language (ie: my recent authorship of a God object).
Wednesday, September 17, 2008
Monday, September 15, 2008
Plone OS projects take two: Radius package and FeedFeeder package
I still haven't made up my mind. Lets go over my options, since working on either can be lots of fun. Do keep in mind my target Plone version is 3.x.
Plone Radius Package
This would be really useful for my job. A Plone package that allows authentication via Radius/RSA would likely mean lots more Plone work for NASA HQ. Once I got a functional prototype I'm sure I could get some funding for more work. Since Wichert Akkerman's pyrad python module is supposedly pure Python this makes integration really easy. I like easy integration.
One thing I like about this potential project is that it should be a pretty quick effort. Actually, the hard part will probably be finding a server to test against.
FeedFeeder Package
Reinout van Rees invited me in a response to this post to take a crack at FeedFeeder when I brought up this issue. The issue?
Feedfeeder assumes the best out of its sources, and assumes that FeedParser is going to return something nice. What if we could make FeedFeeder either assume the worst of its sources, or give FeedFeeder administrators more flexibility in how to handle feeds?
Alas, the problem with RSS (and even Atom) is that people consider the specification (if they actually look at the specification) as mere loose guidelines. I'm not going to point any fingers at anyone because I like my job, but I will say that the ability of Web Browsers to look at anything remotely like RSS and then display the contents like a feed makes life for us Plone developers a pain in the butt.
Periodically, I got people saying, "Include this as a feed!" until I trained them to realize that most RSS feeds are junk. Which is nevertheless embarrassing when the so-called feed that displays as an RSS feed in Firefox or Safari is completely screwy when it comes the XML. In fact, at my job we've pretty much forked FeedFeeder in order to support customer requests, with each RSS feed item being a custom script. The results work and yet are not very pretty.
So my big idea is this that FeedFeeder would be enhanced in one of two ways:
BTW, Reinout van Rees has responded to all my posts on the subject of FeedFeeder. He commented on my first post, which was me whining about not reading the code, to the second which was deliberating on making a RSS package that was like FeedFeeder, but could handle problematic RSS better.
So hopefully Reinout is going to read this post too and share an opinion. ;)
Plone Radius Package
This would be really useful for my job. A Plone package that allows authentication via Radius/RSA would likely mean lots more Plone work for NASA HQ. Once I got a functional prototype I'm sure I could get some funding for more work. Since Wichert Akkerman's pyrad python module is supposedly pure Python this makes integration really easy. I like easy integration.
One thing I like about this potential project is that it should be a pretty quick effort. Actually, the hard part will probably be finding a server to test against.
FeedFeeder Package
Reinout van Rees invited me in a response to this post to take a crack at FeedFeeder when I brought up this issue. The issue?
Feedfeeder assumes the best out of its sources, and assumes that FeedParser is going to return something nice. What if we could make FeedFeeder either assume the worst of its sources, or give FeedFeeder administrators more flexibility in how to handle feeds?
Alas, the problem with RSS (and even Atom) is that people consider the specification (if they actually look at the specification) as mere loose guidelines. I'm not going to point any fingers at anyone because I like my job, but I will say that the ability of Web Browsers to look at anything remotely like RSS and then display the contents like a feed makes life for us Plone developers a pain in the butt.
Periodically, I got people saying, "Include this as a feed!" until I trained them to realize that most RSS feeds are junk. Which is nevertheless embarrassing when the so-called feed that displays as an RSS feed in Firefox or Safari is completely screwy when it comes the XML. In fact, at my job we've pretty much forked FeedFeeder in order to support customer requests, with each RSS feed item being a custom script. The results work and yet are not very pretty.
So my big idea is this that FeedFeeder would be enhanced in one of two ways:
- Custom Scripts - FeedFeeder administrator can do TTW scripts (portable via Generic Setup) to control how FeedFeeder parses the incoming feed. The scripting would be restricted Python. This way the same feed that can be seen via the browser can now be interpreted by FeedFeeder as well. The problem is the normal sort of issues you get with TTW programming, especially when it comes time to validate the script, or port it around (Even with Generic Setup).
- Custom Plugins - How about a plugin system of some sort? Basically, you would follow a standard API and put your plugins in a particular folder. FeedFeeder would pick up the plugin and run the appropriate plugin (we would have a selector tool) against the appropriate feed. This way we could grow the functionality and robustness of the tool as more RSS and Atom feeds are added, and could also support new protocols as they become popular
BTW, Reinout van Rees has responded to all my posts on the subject of FeedFeeder. He commented on my first post, which was me whining about not reading the code, to the second which was deliberating on making a RSS package that was like FeedFeeder, but could handle problematic RSS better.
So hopefully Reinout is going to read this post too and share an opinion. ;)
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.
Friday, September 12, 2008
Some ideas for open source Plone Products
- RSA Authentication Plugin (I know they have them for Zope, but perhaps making them Plone 3 friendly if that is needed?)
- Robust RSS/Atom consumer (I've worked with FeedFeeder. It is pretty good but has trouble handling ugly RSS feeds. Maybe I should just contribute to FeedFeeder?)
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.
Saturday, September 6, 2008
I've not quite done LAMP, or have I?
It hit me just now that while I've played with all the individual bits of LAMP (Linux, Apache, MySQL, Python), I've never actually done LAMP per se. I tend to play with Plone/Zope professionally, and in my goof off time I prefer to delve into wxPython, with my Django work being all too rare. I'm wondering if it might be worth it to do some formal LAMP work, and there might be available work at NASA for it real soon.
On the other hand, according to the Wikipedia entry on LAMP the 'M' in LAMP can mean 'middle-ware'. In which case I am professionally doing LAMP every work day.
On the other hand, according to the Wikipedia entry on LAMP the 'M' in LAMP can mean 'middle-ware'. In which case I am professionally doing LAMP every work day.
Subscribe to:
Posts (Atom)
