<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://mikerozlog.ulitzer.com"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>Latest News from Mike Rozlog</title>
 <link>http://mikerozlog.ulitzer.com/</link>
 <description>Latest News from Mike Rozlog</description>
 <language>en</language>
 <copyright>Copyright 2012 Ulitzer.com</copyright>
 <generator>Ulitzer.com</generator>
 <lastBuildDate>Thu, 17 May 2012 12:24:16 EDT</lastBuildDate>
 <docs>http://backend.userland.com/rss</docs>
 <ttl>360</ttl>
<item>
 <title>The History of Programming</title>
 <link>http://mikerozlog.ulitzer.com/node/1879986</link>
 <description>I’ve been programming since around 1982, first using an Apple in high school and then finally getting my first computer, the Timex Sinclair 1000 (2k of ROM and 2k of RAM), that same year. Both computers came with a form of the BASIC programming language and it was the start of my lifelong pursuit of trying to understand computers.
A few months ago, one of my good friends called and asked if I had a PowerPoint presentation on the history of programming. When I checked my extensive list of presentations, I noticed that I didn’t have one, so that led me on a journey to create a presentation on that very subject. 
However, where to start? Maybe 1940 or 1950? After thinking about it for a while I realized that’s really not where programming started. You need to go way, way back to really understand the programming concept and where it came from. This led me to envision the world as a dark, almost black place with a small white light in the center… really the only light around was the small white light in the center and that light represented the idea: there has to be a better, more accurate, way to count and keep track of things for commerce.&lt;p&gt;&lt;a href=&quot;http://mikerozlog.ulitzer.com/node/1879986&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Mon, 27 Jun 2011 12:15:00 EDT</pubDate>
 <guid isPermaLink="true">http://mikerozlog.ulitzer.com/node/1879986</guid>
 <comments>http://mikerozlog.ulitzer.com/node/1879986#feedback</comments>
</item>
<item>
 <title>Standardized Tooling: Building Bridges, Not Walls</title>
 <link>http://mikerozlog.ulitzer.com/node/941430</link>
 <description>Some walls are necessary. We use brick-and-mortar walls to support buildings and firewalls to protect our computers from attack. But not all walls are good. Consider the Berlin Wall, a wall of segregation. It divided a country and its citizens, but has subsequently been brought down by people working together because upon re-evaluation the Wall did more harm than good.&lt;p&gt;&lt;a href=&quot;http://mikerozlog.ulitzer.com/node/941430&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 29 Apr 2009 15:45:00 EDT</pubDate>
 <guid isPermaLink="true">http://mikerozlog.ulitzer.com/node/941430</guid>
 <comments>http://mikerozlog.ulitzer.com/node/941430#feedback</comments>
</item>
<item>
 <title>Software Archeology: What Is It and Why Should Java Developers Care?</title>
 <link>http://mikerozlog.ulitzer.com/node/487614</link>
 <description>The term Software Archeology has been used in various forms since early 2001. The concept of Software Archeology is an approach or methodology that helps individual team members or entire teams to understand exactly what they have in the code they&#039;re going to be working on. The approach is also very useful when deconstructing an existing piece of software to find patterns of design and development that could be &#039;harvested&#039; in future developments.&lt;p&gt;&lt;a href=&quot;http://mikerozlog.ulitzer.com/node/487614&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Mon, 28 Jan 2008 11:00:00 EST</pubDate>
 <guid isPermaLink="true">http://mikerozlog.ulitzer.com/node/487614</guid>
 <comments>http://mikerozlog.ulitzer.com/node/487614#feedback</comments>
</item>
<item>
 <title>Disaster Recovery Plans Be Prepared</title>
 <link>http://mikerozlog.ulitzer.com/node/159572</link>
 <description>It would seem only logical that after 9/11, one of the most horrific days in American history, corporations large and small would be ready for unforeseen catastrophic events. However, by one recent estimate, less than 38% have put a complete disaster recovery plan in place - the policies, processes, procedures, and architecture to deal with unforeseen events. In the wake of Hurricanes Katrina and Rita, IT managers are again forced to reassess how well prepared they and their organizations are to manage through and recover from natural or man-made disasters.&lt;p&gt;&lt;a href=&quot;http://mikerozlog.ulitzer.com/node/159572&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Mon, 26 Dec 2005 10:15:00 EST</pubDate>
 <guid isPermaLink="true">http://mikerozlog.ulitzer.com/node/159572</guid>
 <comments>http://mikerozlog.ulitzer.com/node/159572#feedback</comments>
</item>
</channel>
</rss>

