This is a special edition of Ten Minute Tech, because I am announcing the I am going to stop writing these for a little while. I have decided to put on hold publishing any more of these until I can build up a wealth of resources and topics.

I want this program to force/enable me to really dive into some technical topics that I wouldn't otherwise study. But what I am finding is that I am continually short of topics and trying to write an article on just something random at the last minute. So I am going to stop focusing on meeting my weekly deadline and focus more on learning about technology. I plan to start compiling topics and research and once I have built up enough articles and information I will start publishing my weekly article again. I was just trying to be a little too ambitious. However I do only plan to take TMT off line for a month or two; so by the early to mid summer I should be back at it.

This is an installment of Ten Minute Tech; where I pick a technology related subject and then write a paragraph or two about what I know. I then pick and read a reference article related to the subject and then write another paragraph or two about what I learned. This edition's topic is about the Software Development Life Cycle.

Before

I have been reading up on software development methodologies lately because I am currently in the process of redeveloping our companies policies when it comes to planning and executing development projects for our clients. This was also one of the topics I covered in the seminar I gave at Tri-C last fall.

The Software Development Life Cycle is an abstract model of the process of developing a piece of software. That is to say it defines that actual steps a person or group should take when developing a new software application. It lays out a set of steps (usually five to seven) that take the software project from research to coding and then implementation and maintenance. There are many varied methodologies and subprocesses involved under each step; some of which are based on strict standards while others are more abstract.

The steps vary depending what your reference is, but they generally include:
- define requirements
- analyze and model
- code
- implement and test
- maintain

Article: Software Development Life Cycle

After

This article lays out the steps a little different than I am used to, but the overall flow fundamentally achieves the same idea (plan, code, implement, test, maintain). It also goes into the details on how this model is actually applied. Overall it is a well written article but it could use some better referencing throughout.

Of the handful of process models they discuss, I would say I am most familiar with what would be considered the iterative or agile process. This is because I develop mostly in a corporate environment where clients want to see tangible results (which requires coding) even before they are able to define all of the requirements for us.

This is an installment of Ten Minute Tech; where I pick a technology related subject and then write a paragraph or two about what I know. I then pick and read a reference article related to the subject and then write another paragraph or two about what I learned. This edition's topic is about the Open Systems Interconnection Basic Reference Model (OSI Model).

Before

To be honest with you there is not a lot that I remember about this model outside of the fact that it exists. If I can recall my college days properly the OSI Model was developed as a way to standardize transmission methods for networks.

Article: Open Systems Interconnection Basic Reference Model

After

As I understand it is an abstraction to describe communication and network protocol design. It is broken into seven layers, with each layer having its own set of responsibilities. It is a logical representation of network based transmission and is used only as a theoretical model. The model was designed by the International Organization for Standardization in the 1970's and has been a major influence in the design of most modern day transmission protocols.

I am not going to describe each layer in detail here; the article itself does a nice job of describing it as well as provides a table showing where modern protocols operate in order to handle communication. Since this model is just a logical design model, most modern day protocols operate on several levels of the model.

There was a good reference to an article that helps describe the function at each level of the model by putting it in terms of James Bond transporting a secret message.
James Bond Meets The 7 Layer OSI Model

This is an installment of Ten Minute Tech; where I pick a technology related subject and then write a paragraph or two about what I know. I then pick and read a reference article related to the subject and then write another paragraph or two about what I learned. This edition's topic is about Document Type Declaration's.

Before

In my opinion Document Type Declaration's (DOCTYPE) are one of the most overlooked items when it comes to web development. What I mean is that many developers don't use them at all or they use but don't understand why they should. It really is remarkable how using a proper DOCTYPE in your xhtml files can effect the rendering of your pages, especially when it comes to cross browser coding.

I am not going to go into too much more detail about how a proper DOCTYPE can effect web page rendering (volumes could be written on it); I guess I am just really tired of people still complaining about the Box Model problem in Internet Explorer 6 (if they would use a proper DOCTYPE they wouldn't have to worry about it).

Now, a DOCTYPE is an instruction (line of code) that links to a file that describes the markup syntax for the rest of the page. Its most practical application is for use at the top of an xhtml or html page to describe to the browser what tags and attributes the page can use in the xhtml/html code. The file the DOCTYPE links to is a language of it own know as a Document Type Definition (DTD).

For a non-technical example take the English language. If you were writing a letter to your friend in English and you wrote at the very top of the letter 'This letter is written in English'. This would be equivalent to the DOCTYPE. You are simply stating right away what someone is going need to understand in order to read the rest of the letter.

The Document Type Definition (DTD) would be the dictionaries, thesaurus and grammar books that some could use to decipher the message (if they didn't already know the language).

For the computer a proper DOCTYPE not only declares the language, but it also tells the computer where to find the DTD. This would be like you not only writing the fact that the letter is in English, but also listing a bunch of ISBN numbers for the person to lookup the English books.

DOCTYPE's and their definitions are typically used to define markup languages (html, xhtml, rss, soap, etc); but I believe they can be extended to almost any type of syntax (if only in theory).

As far as the syntax of the DOCTYPE itself, I myself can never remember, I always have to look them up.

Article: Document Type Declaration

After

The article itself is actually very narrowly written. It focuses on the various html and xhtml DOCTYPE's (maybe should be expanded). It does however mention the fact that it is used for SGML and XML based documents.

I think the real potential in DOCTYPE's and DTD's is the the idea that they are a practical application of a way to create a computer readable language that describes other languages (i.e human languages). I think that this could really be the foundation of something much greater. Just think of a time that we could truly teach a computer how read and understand a human language. The applications in translation and human to computer understanding could be great, and I think we will slowly grow in this direction. I would be interested to know if there are projects and studies out there today that are working toward this very thing.

Some good additional reading is the article on Document Type Definition's. It goes into the nuts and bolts of how these technologies are used today to describe custom markup languages. Unfortunately this article does not talk about the theory behind it.
http://en.wikipedia.org/wiki/Document_Type_Definition

Here is an article on markup languages in general. It briefly touches on the idea of semantic markup; the idea that the code reflects the [human] meaning of the information inside of it.
http://en.wikipedia.org/wiki/Markup_language

This is an installment of Ten Minute Tech; where I pick a technology related subject and then write a paragraph or two about what I know. I then pick and read a reference article related to the subject and then write another paragraph or two about what I learned. This edition’s topic is about the GNU Public License.

Before

Let me first start by saying that this article does not in any way resemble or imitate proper legal advice, when it comes to software licensing. It furthermore does not replace the need for you to read the GNU General Public License yourself before accepting and/or using it. This article is just intended to highlight the basic ideals behind the license and somewhat of the idea of free software as a whole.

I have been using and even writing (or helping to write) code that has been protected by the GNU General Public License (GPL) for years, but I never have read it myself to see what it really means. For that matter I have never read any of a slew of Microsoft software licenses that I have definitely agreed to over the years either. So I want to read the GPL, especially now that I pretty much live and work with various open source technologies on a daily basis.

I do however like to think I have an idea of what free software is and that it is the GPL that is trying to legally establish and protect that. My idea of free software is not that it is free in the sense that you don't pay any money to download and install it; it is free in the sense that the code that created the software is protected such that it can be given out freely and ensured that it is only used to create newer and better free software. The idea that it can never be owned; as the saying sometimes goes 'free as in speech, not free as in beer'.

Article: GNU General Public License

After

After reading the license, I think it really focuses on two points. The first of which is ensuring that any program (as they call it in the license) that is initially protected by the GPL remains free under the terms of the license. One of the big pinnacles of this is that a GPL protected program will always offer access to its source code. This idea is that a free program will remain free; and also that someone who writes a free program will never have to worry about someone else taking that program and using or reselling it under a non-free license even though the source code is available.

So for example I could never just take Open Office and recompile it and then sell it as a closed source competing office suite product. I could however release a slightly modified version of Open Office as long as I released it under the GPL as well (i.e. make it free also). Open Office is actually protected by the LGPL (modified version of the GPL), but it is an example that I think more people will be able to follow.

However this is not to say that you can never use GPL protected software in a closed source, commercial application. For example it is well within your rights to take MySQL and then build some web based software (perhaps a CMS) and not release the code under the GPL. This is covered under the idea that closed source application uses the software and is not based on the underlying code (i.e. my CMS could work with different database software). What couldn't be done is take MySQL and release a closed source database management system.

On this same note there is also a lot of regulation in the license about maintaining original authors and source (as in what the originating program was) and about documenting the changes you make to the original GPL protected free software.

The second main focus (that I noticed) of the license was more in regards to the users of GPL protected software in that the software itself was presented 'as is' and without warranty. This is to protect the developers and organizations that create free, GPL protected software, in that they couldn't be sued if it didn't function as advertised for a particular user. This was, I think added as a way of encouraging developers to use the license by offering some protection.

To be quite honest here in my closing; I don't feel as if I have done the license justice by trying to explain it here. The idea of free software and what the GPL actually covers is much more complex than these few paragraphs. The preamble of the license does a much nicer job of explaining the basics, so I would encourage everyone to read the license itself.

You will notice that the GPL is rather strict and specific. Some further reader would be the GNU LGPL (GNU Lesser General Public License). It is different in the sense that offers a little more flexibility in the usage and modification of code (opens up more proprietary possibilities).
http://www.gnu.org/licenses/lgpl.html

This is an installment of Ten Minute Tech; where I pick a technology related subject and then write a paragraph or two about what I know. I then pick and read a reference article related to the subject and then write another paragraph or two about what I learned. This edition’s topic is about MD5 (Message-Digest algorithm 5).

Before

MD5 is a form of one way encryption; sometimes called a hash. Basically it a way to take an existing amount of data (for example a user's password) and scrambling it such that it could not be unscrambled. Well, given today's fastest computing power it would take many years to decrypt.

A user password for a website would be a great example. Let's say you register a user account for a website and they take and keep a password of your choosing. They are going to be storing this password somewhere. Now it would be more secure for them to store the md5 version of you password. They could always convert the password you provide at the login prompt to compare it to the stored encrypted version; however if someone was able to hack into their user database all they would see is an MD5 version of your password and would never be able to use that to login as you.

It is also used in email, to verify that the email a person receives is the same as was sent by the sender. I this case the sender's email client would send the message and an md5 version of the message. The recipient's email client would run an MD5 of the message that it received and compare it to the md5 string that was sent. It would help verify that the message was not tampered with or corrupted en route.

Article: MD5 (Message-Digest algorithm 5)

After

After reading the article, I have learned that the MD5 algorithm is based on bit rotation (the bits of the original content is shifted to the left at algorithmic intervals). However I have learned that the security level of the MD5 algorithm in truth is not that high. In that there have been very efficient algorithms developed that can decrypt an MD5 hash in less than hour using average computing power. Also many lookup tables have been developed to shorten the decryption process.

There are a few methods to improve the level of security. One is that you can add what is called a salt, which is some predetermined data that is added to further obscure the original data. A second method is that the MD5 algorithm could be performed a number of times (with or without salts).

However, MD5 is widely used to offer some basic protection to passwords; but it's primary function anymore is to help ensure the validity of a file (similar to my email example). They can be generated for files that are transfered over a network and then used to ensure the the transfered copy is the same as the original. You will see this a lot on the web with large downloadable files.

Here is some interesting follow up reading on why MD5 is not that secure and how it can be broken.
http://en.wikipedia.org/wiki/Rainbow_table
http://en.wikipedia.org/wiki/Birthday_attack

This is an installment of Ten Minute Tech; where I pick a technology related subject and then write a paragraph or two about what I know. I then pick and read a reference article related to the subject and then write another paragraph or two about what I learned. This edition's topic is about the Advanced Research Projects Agency Network.

Before:

As well as I can tell it the Advanced Research Projects Agency Network (ARPANET) was the fist packet switched network and the direct predecessor of what we now know as the Internet. It was created sometime in the mid 1960's by the United States' Department of Defense.

My understanding is that it was the first electronic network of its kind because of its ability to communicate using packets of information. The idea of packets is that a single message or bit of information could be broken into several smaller chunks and then sent separately over the physical communication lines and then reassembled in one message once all packets were received. This could allow the simulation of simultaneous communication over a single line; understanding that a single line wouldn't have to been tied up until the entire message was finished before accepting another one.

Article: Advanced Research Projects Agency Network

After:

In addition to what I already understand, the ideas behind the ARPANET were formulated in the early 1960's by J. C. R. Licklider in his memos suggesting the idea off a "Galactic Network". He was later given a position at ARPA and then started bringing others into the project. It wasn't until 1968 that the full plan for the ARPANET was completed.

It was in 1968 that ARPA put out a Request for Quotation (RFQ); which was received as 'outlandish'. Only twelve bids to complete the project were received and of which, only four were taken seriously.

The infrastructure was composed of (initially four) computers that were connected to dedicated, leased lines at 50 kbit/second. These computers (known as an IMP) handled all of the network routing and would sit at any location that wished to be connected and could support up to four machines.

The entire project including the hardware and route software was completed in nine months.

When the ARPANET was launched it was setup at four locations (potentially supporting connections for sixteen machines). The first of which being UCLA on October 29, 1969.

The IMP's handled transmission by software called Network Control Program (NCP) which was designed to allow higher level software (protocols) to be written for it. It was this capability allowed for the creation of email and file transfer (FTP) protocols which we still use (a form of) today. Also voice transmission was created, but was never realized due to hardware difficulties of the time. It wasn't until 1983 that TCP/IP replaced NCP, which is what we used today.

One common misconception about the roots of the network is that it was conceived out of a demand for an information network that could survive a nuclear disaster. However this was just a realized benefit after it was already up and running for a few years. It was truly conceived out of a lack of mainframe machines that researchers across the nation could utilize due to geographical restrictions.

With the advent of the new year I have decided to try change the way I research and then subsequently write articles. I still plan to keep an eye on the articles and stories in the news and also write about the random experiences I have with various technology. However I want to start an initiative for myself that will get me to read about things that wouldn't necessarily come across my desk.

This is the essence of 'Ten Minute Tech'. I plan to seek out a reference article (or book) of some kind on a technology topic that I don't necessarily know anything about. Once I find this article I plan to take a couple of minutes to write just a paragraph or two about what I know (or at least think I know) about the topic of the article; and then I will read the article and then write another paragraph or two reflecting on what I learned about the topic from the article (and how it has shifted my perspective).

I have already picked out my first article and it is my goal to release a new one of these 'Ten Minute Tech' articles every Tuesday starting on the first Tuesday in February (Feb 6, 2007).

Of the few people I know that actually read my blog on a regular basis; I would ask of you to help keep me honest as well as pass along any topic or article ideas that you think are interesting.