So, I’ve been going a little crazy with the analog photography lately.

I like that flickr displays the EXIF metadata to let you know what kind of camera took that photo. Obviously pictures that are a scan of photo taken with a non-digital camera do not contain that information. so, i did a quick search on the cpan and found Image::MetaData::JPEG

after reading some docs and using Data::Dumper i was able to come up with this script that sets the make and model info. here is an example I took with my Kodak Jiffy Six-20. if you find this useful, let me know…

download exif_makemodel.pl

After 13 years of the O’Reilly classic, Managing Projects with make, 2nd Edition, coauthor Andy Oram looks back and summarizes the evolution of make. With the recent release of Managing Projects with GNU make, 3rd Edition, author Robert Mecklenburg offers an adapted excerpt comparing Ant, IDEs, and make for managing the build process.

[read the article]

here is a couple of tips for getting subversion and Xcode working together.

• if you have subversion installed in a non-standard location you can set the path like so:

  defaults write com.apple.Xcode XCSubversionToolPath /usr/local/bin/svn
  

• from: http://www.pycs.net/bbum/2004/2/28/

  Since the pbxuser file tracks window positions, file scroll positions, and other information that tends to change often, the differences between any two revisions of the pbxuser file tends to be large. In the context of automatic change notification emails, this tends to be really annoying in that it is this huge chunk of completely irrelevant noise that obscures the useful bits within the notification email. Given that pbxuser is XML, the changes between two revisions aren’t really readable in diff form anyway. Easy fix: tell Subversion that the file is binary. This is simply a matter of setting the mime-type appropriately.

  cd *.xcode
  svn propset svn:mime-type application/octet-stream *.pbxuser
  svn commit -m 'Set mime-type of pbxuser to application/octet-stream to binary.'
  

Through his LibraryLookup project, Jon Udell finds that you don’t need to understand what REST is in order to benefit from its use in a system.

[ read the article]

(an older article, but I found it quite good)

You’ve rolled out an application and it produces mysterious, sporadic errors? That’s pretty common, even if fairly well-tested applications are exposed to real-world data. How can you track down when and where exactly your problem occurs? What kind of user data is it caused by? A debugger won’t help you there.

[read the article]

One seemingly bankable trend is that every day computer languages become easier to understand, and become more like human languages. The concept that easier to understand languages could lead to less error prone and more rapid development was the basis for Fortran II way back in 1958, and the foundation for the high-level languages of today. Since the 50s, however, numerous high-level languages have propped up. You’ve heard and worked with most of these. Fortran is still used in engineering, and general programming problems are often solved with C, C++, Java, and Perl, which are all considered high-level.

But what about the more obscure high-level languages? Dozens of paradigms have propped up, and every day there seems to be a new language on the block. Here is a handful of popular modern high-level languages, what they are being used for, and where they are hiding in the industry today.

[read the article]

Text processing is one of the most common tasks in application development. Whether it is a Java Servlet or a VOIP application, the conversion from a raw text-based input message to a machine-readable internal representation almost always requires parsing (or tokenization), which, in its current form, refers to a process of extracting tokens (the smallest unit of relevent textual information) and storing them in null-terminated memory blocks, also known as strings. Over the years, people have invented various automation techniques and tools, e.g. regular expression and Lex, to reduce the complexity of manual parsing. Proven both useful and stable, those techniques and tools have stood the test of time. As a result, the current framework of text processing is generally considered to be fairly well-established.

[read the article]

So you want to write a program to read RSS and Atom syndicated feeds. Sounds simple enough. After all, RSS stands for “Really Simple Syndication” (or “Rich Site Summary”, or “RDF Site Summary”, or something), and Atom is just RSS with different tag names, right? Well, not exactly.

[read the article]

Interesting article by Randall Hyde over at ONLamp.com on writing good code:
The world is full of case studies outlining software engineering disasters. Almost every programmer has had to work on a project involving “less than stellar” source code that was difficult to read and maintain. On rare occasion, some programmers get the opportunity to work on a well-designed system, an awe-inspiring piece of craftsmanship that usually produces the exclamation, “This is truly great code!”
Clearly, professional software engineers should strive to achieve this level of greatness in all their code. But the real question is, “What makes code great?” Simply “meeting specifications” is not how one writes great code…
[read the article]

Mac OS X Panther includes many updated developer tools. Among them is an enhanced version of Python 2.3 with its own SWIG-based bindings to the CoreGraphics library. Creating PDFs, JPEGs, and documents in other graphical formats just became a lot easier.
read the full article