Ok, so I'm predictible.
As someone who discovered computers just about the time the idea of the PC was reaching the market, I'm one of those who has been fully immersed in the hacking culture. I never was as hardcore as the guys who wardialed the Pentagon, or build my own computer from NAND gates, but I got my PC as soon as I got out of college, and have been programming in some form for almost 30 years.
For me, the defining hacker trait is curiousity. You want to know how something works, or want to build one for yourself. It manifests most strongly in computers, I think, because software is so malleable that once you've bought the computer and get a compiler/interpreter, you can make nearly anything. In contrast, electrical engineering hacking requires you to buy parts, which limits your work. It's also much easier to prototype in software than in hardware, and you almost never blow up parts in the testing.
At the present time, it's a sad truth that the US is drifting away from the hacking spirit. The advent of offshoring has made software a precarious career, and colleges are starting to move their curricula away from the fundamentals of software. So many of our products are packaged so that there are no repairable parts in them. But a few rays of hope are shining - Make is publicizing hacks, and the very flood of disposable technology is spurring hackers to try things, since they are so cheap to buy.
I hope the trend picks up speed. I'm looking forward to some of the cool things lurking around in people's skulls.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Friday, February 24, 2006
Tuesday, February 21, 2006
Software Tools
These days there are a great many tools that developers can use to create software. There is UML and the various products that use it. The Java world has Struts and its successors for application development. Ruby on Rails is currently enjoying popularity as a web application development platform.
What all of these have in common is a development style that they will tend to enforce on your team. This is not a bad thing, but it is something to be aware of, especially if you are using two or more with styles that conflict, or any that conflict with the company's process style.
An example of this is most UML products. They tend towards the process-heavy side of the spectrum, and recommend the full Analysis/Requirements/Design/Development/Testing cycle. If you are working in a Agile style, these tools will be a significant deviation from your accustomed process, and you will need to take this into account when shopping for the UML tool.
Another example is Rational Rose. One of the earlier versions was integrated with a relational DB mapping tool called Persistence. You could draw your UML class diagrams in Rose, and drop them into a generator that would generate the files that Persistence would use to generate the database access library code. The wrinkle came in that there was no way to split the UML into sections and have it generate database code that referenced tables not in the specific UML diagram. So you ended up with one huge monolithic database library, that took a long time to generate and build, making it painful to make database changes; the alternative was to split the UML into logical sections, but you would lose the database integrity checks, because the tools could not link across diagrams.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
What all of these have in common is a development style that they will tend to enforce on your team. This is not a bad thing, but it is something to be aware of, especially if you are using two or more with styles that conflict, or any that conflict with the company's process style.
An example of this is most UML products. They tend towards the process-heavy side of the spectrum, and recommend the full Analysis/Requirements/Design/Development/Testing cycle. If you are working in a Agile style, these tools will be a significant deviation from your accustomed process, and you will need to take this into account when shopping for the UML tool.
Another example is Rational Rose. One of the earlier versions was integrated with a relational DB mapping tool called Persistence. You could draw your UML class diagrams in Rose, and drop them into a generator that would generate the files that Persistence would use to generate the database access library code. The wrinkle came in that there was no way to split the UML into sections and have it generate database code that referenced tables not in the specific UML diagram. So you ended up with one huge monolithic database library, that took a long time to generate and build, making it painful to make database changes; the alternative was to split the UML into logical sections, but you would lose the database integrity checks, because the tools could not link across diagrams.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Subscribe to:
Posts (Atom)