Bread & Butter

• Python – My language of choice for the year.  Whether prototyping, experimenting, developing a Facebook application, maintaining a test framework I wrote for my workplace, or implementing cryptographic algorithms for a security course, Python continued to serve me well.  Between a copy of “Python Essential Reference” and PyPI, I feel there are very few problems beyond my means thanks to the power of this beautiful language and its surrounding community.
• Java – As a student, I pounded out many a line of Java throughout the wee hours of the morning in my capstone classes.  Java seems to be the New Age language of academia and I can speak it universally to my classmates and professors as a lingua franca.  I’ve noticed that my Java programs tend to structure themselves well without much effort thanks to the strong object influence forced by Java and expansive standard library and Collections classes.  Also used at two collegiate programming competitions which is an entirely different experience than normal software development where the large standard library again came in handy.

Good Progress

• C – I launched a good sized networking project in C as my first big project in the language and contributed a number of portability fixes to the libevent project.  Fast to compile, fast at runtime, and full low level control, C is a great language for Unix Systems Programming.  I greatly expanded my knowledge of the POSIX interfaces this year and really enjoy programming at this level.  I’ve noticed that some principles from other higher order languages have rubbed off on my C style; namely, data hiding and well formed/adaptable interfaces (see the post right before this one).
• C++ – Been putting this one off because of all the FUD and intimidation at the sheer size of it.  C++ is pretty much the Latin of our field and is used in everything from safety-critical Jet aircraft systems, to GUIs, to games, to JITs, to cutting edge research.  As some of the pundits say, C++ is the language for “Demanding Applications”.  If you consider Java as the Flight Engineer of a large aircraft, C++ is definitely in the Pilot seat.  You have full control and high visibility of what is going on, but if you aren’t careful you can crash and burn.  I’ve probably progressed to the advanced beginner stage where I can use it as a better C but haven’t endured the trials and tribulations of an expert in the art of C++, nor read important references like Scott Meyers’ “Effective C++” series.  I really like the power and efficiency of the STL and plan on knowing enough C++ to use it when called upon.

Breaking New Ground

• VHDL – After a required Electrical Engineering course, I was exposed to the entirely different paradigm of programmable hardware (FPGAs).  This was an eye opening experience.  Fundamentally, digital design is concurrent.  There may be valuable lessons here for both academic and professional Computer Science and I need to explore more here.  In 2011, I’d like to buy my own FPGA development board and work through the design of a simple CPU to gain further appreciation of hardware and VHDL or Verilog.

Back Burner

• PHP – The first language I seriously learned and used some 12 years ago (I dabbled in Perl before that at the ripe age of 8, and probably Lego Logo a year before that :-P ).  I’ve been keeping an eye on it and it seems some of the Framework movement that stole a lot of developers away to other languages has sprouted mature analogues in PHP land.  No longer just C for the web, PHP 5.3 continues the lineage of the 5-series as a serious object-oriented language for web development that is basically universally available and dead simple to scale.  The extent of my PHP coding in 2010 was limited to maintaining some programs I’d written in years past (aside from merely installing/using PHP products like this blog).

On to 2011

• D – D2 has me really excited.  For some intents and purposes, it seems like an evolution of C++ with a healthy removal of backward compatibility.  Embracing fast compile times, integrating concurrency and message passing, allowing easy interfacing to C libraries, and more mean this is a language capable of “Demanding Applications”.  Perhaps most intriguing is the use of the language proper for metaprogramming and compile-time programs.  I have Andrei Alexandrescu’s book on my shelf and have thumbed through it a few times.  The fact that he is involved speak volumes of D’s potential and his book looks superbly written. 2011 means working my way through the book and working on at least one sizable project in D.
• Erlang – Erlang has been on my radar for a couple years now.  The fact that the OTP has roots in the demanding and critical realm of telecom means this is a serious language and seems to deliver interesting take on concurrency.  Erlang has already proven itself effective for XMPP servers and Message Queues.  This may yet be one of the best languages around for scalable networking applications and I’d like to get some hands on experience with it in 2011.
• Haskell – I don’t know much about Haskell other than playing around with TryHaskell.  What I do know is that Haskell has a fairly mature Software Transactional Memory and that alone interests me.  I’ve also heard the optimizing compiler is pretty good.  Through investigation is due in the second half of the year.

No related posts.

This sends a couple of messages:

1. Oracle doesn’t think Solaris/OpenSolaris is viable on the workstation
2. Oracle can’t deliver low margin hardware (the prices on these boxes skyrocketed after the acquisition)

It could be a purge while they bump to a new model featuring 6-core Xeons.  Yet more than likely, another victim of the merger.

No related posts.

Before you do this, please consider the Kev009’s Oath – “But First, Write No Code”.  This is a solution to a variety of problems in software development, but today’s article is specifically on using external code.

I’ve found that programmers who follow a system similar to mine (detailed below) develop systems that are more stable, maintainable, and sane.  They likely write better code because it means they understand their tools and also read others’ code.  They examine the problem first rather than going in guns blazing.

Steps to decide whether to use an existing solution or write your own implementation:

1. Scan the area. Google, Freshmeat, SourceForge, standard library, OS libraries, etc. are your friend.  See if the problem you are trying to solve has been solved.  I don’t care how long you’ve been programming or how much you think you know. The ecosystem of a language is constantly changing.Make a list of hits that look similar to the problem you are trying to solve.  Try and get a quick sense of the idiomatic methods of using your language, OS, etc.
2. Do research. Are the solutions you found in step 1 suitable to the problem at hand?  Consider the pros and cons of each item.  Now, carefully evaluate how idiomatic the items are to your language and environment.If the item is open source, does the community seem active?  If it doesn’t fully map to your problem, does it look like you can modify it to do so?

   Even if you end up developing a solution from scratch, you should at least now have some good references.  Keep in mind, extending an existing project may be considerably less work.  You might even be able to offload maintenance of that component.

3. Consider the license. This isn’t just for the legal department.  What kind of project you are working on will weigh in heavily.  Commercial or open source?  As a software professional, you need to be abreast with the various licenses in the wild.  As an open source developer, you need to consider how licenses will affect your work being packaged by distributions.An open source library licensed under the GPL is not acceptable for static linking to commercial software.  However, you can link to an operating system provided copy or bundle the dynamic library with your application.  LGPL does not have this restriction.  With both of these, you must supply your changes upon request from end users among other things.

   BSD, MIT, and Apache style licenses allow you to make changes and redistribute under completely different licenses.  Some just want credit in your documentation.  These are very compelling even in commercial development.

   Commercial components may have a per-copy fee associated which may dissuade their use by your organization.  If you don’t get the source, you won’t be able to effectively change or maintain it so you will also be at mercy of that developer.

4. Make a decision. By now, your list should have been pared down based on licenses and research.  Perform extensive evaluations of the remainder and eventually hone in on the one you think fits best.  You’re going to have to rely on your experience and intuition while making the critical decision.  Perhaps the hardest part:  weighing it against a mythical home-grown solution in your mind.
5. Implement the decision. Self explanatory.  This either means bootstrapping your own project or fully integrating the external one.  If you are extending an open source solution, consider submitting the patches back to the community for feedback and perhaps integration.  If you are bootstrapping your own solution, you’ve got your work cut out.  Is this only suitable for an internal project, or perhaps it would have its own merit as a new open source project?Be sure to reevaluate early and often.  That library you chose might turn out to be a can of worms, just as the “easy” new solution you had in your head might require years of development.
6. Subscribe to the announce mailing list. Only if you used an external solution. Does the project have an RSS feed for releases or a low volume announcement list?  Don’t be like Adobe.  Avoid embarrassing security problems.  Also consider how enhancements and bug fixes to the external project might make your own project better, more stable, and more efficient.  This is where the real lasting dividends of using an external solution come from.

This list is widely applicable.  You’ve got a seriously high bar to reach if you are developing containers of <T>, sorting methods, GUI frameworks, parsers, text and binary file formats, and much more so try and follow it the next time you code.

No related posts.

Unfortunately, IBM’s “transmogrifier” utility doesn’t work very well in Wine, so you should preprocess older books in Windows before running them through the boo2pdf web service (download is on that page).

Source code is now available from boo2pdf gitweb.

No related posts.

Motivation

I have a large collection of old IBM machines and documentation. I want this documentation indexed by my own search facilities and Google for easy retrieval. PDF is widely read, while BookManager requires proprietary software and no search engines I know of parse it. This will probably be useful to Mainframers as well.

Take the web service for a spin here:

http://ps-2.kev009.com:8081/boo2pdf/.

No related posts.

I aim to do the same by showing “Java: The Good Parts” here at a high level.

When I was younger, I used to despise Java for political reasons and bad memories of early applets and applications.  I suspect many users and developers (especially Libre software devs!) are on the same boat.  By the end of this article, I hope I swayed your opinion or at least caused you to reevaluate your bias.  I also wish to encourage further discussion about these points and ways we can improve any deficiencies.

Rough and Tumble Upbringing

When Java first started gaining popularity, it was loudly hyped as the end all language.  It was expected that Java would take the “rich client” by storm, and applets would be the go to solution for enhancing web pages.  What happened was a bit different.  Java floundered and struggled to find a niche.  On the client side, AWT apps looked horrendous despite using native widgets.  Then Swing came about and despite easing development, it looked equally bad on all platforms (by default).  Applets were basically a stillbirth.  The ugly gray box, loadtime sometime measuring in minutes, and no coordination with the DOM and web browser made the average user hate Java.

One area Java was able to develop and secure a foundation, however, was the back end of large web applications.  The Virtual Machine approach provided a marked advantage over the CGI and interpreted scripts of the day.  Java’s rich networking libraries, clean Object Oriented design, and safety made this the language de jour for large web applications.

Open Source Matters

In my opinion, the open sourcing of Java during its early infancy would have had little impact on most of the teething issues.  The Virtual Machine, JIT, and Garbage Collection required many years of tuning to get acceptable performance and Sun did an acceptable job keeping it under wing.  The relatively limited CPU and RAM of the mid ’90s also made these concepts a bit ahead of their time.  Somewhere in the 1999-2002 time frame, though, Sun really dropped the ball.  An Open Source Java would have led to ubiquity on the booming Linux platform and a chance for all sorts of cross-platform software.

Open Source matters, and not just for the source code.  Open Source projects naturally bring about very pragmatic and intelligent developers.  These are the folks that thoroughly enjoy their hobby, work, and tools.  The marketing guys and pointed haired bosses have much less pull here.  On one hand, a vibrant community built itself with the many Apache Software Foundation projects.  However, most of these were squarely focused on web applications or low level things such as build tools, testing frameworks, and message buses.

Due to the void, interpreted languages such as Python rose to the challenge while C and C++ remained the mainstay for applications programming.  Microsoft started dominating Windows development with their .NET CLR languages.  The glib/Gtk+ and Qt toolkits brought about a renaissance in cross-platform development with C and C++ respectively [though not limited].

It wasn’t until the open-sourcing of SWT that GUI development in Java became attractive.  The obvious killer apps here were the Eclipse IDE and the Azureus (now Vuze) bittorrent client.

Sun’s closed grip of Java really stagnated any chance of abundant expansion in these middle years (2001-2006).  Microsoft leveraged this weakness to create the excellent .NET platform and associated languages to maintain their closed platform and market dominance.  The counterbalance that would have been Java was thus left playing catchup.

We are just beginning to see the fruits of this labor from 2006 through today.  The OpenJDK project is now distributed with popular Linux distributions such as Ubuntu and Fedora.  We finally have decent browser plugins and Java Web Start applications across 32 and 64-bit machines.  The Java deployment problem will slowly fade from memory.

Application Development

SWT made Java apps beautiful.  OpenJDK should make them ubiquitous.  We finally have an Open Source platform that is widely deployed.  The strong built in standard library and clean OO design patterns of Java make it a very pleasant host for developing rich client apps.  Obvious areas for improvement here include better layout/form design tools and closer integration with upstream Linux distributors.

Somewhere along the line, Trolltech/QT Software (now owned by Nokia) released Jambi — the complete Qt bindings, GUI framework, and incredibly rich library — for Java.  Oddly, this bombshell received little of the community and fanfare I thought it would or deserves.  Indeed, QT Software demoted Jambi from their teir-1 platforms and hopes the community will pick it up.  I hope this project isn’t allowed to stagnate as there is a lot of potential here.

Web Apps

Along the “Enterprise Web Application” lineage of Java, we wound up with some disgustingly overcomplicated and bloated frameworks for building web apps.  Ruby on Rails and Python Django came about and put a new spin on the development of rapid and robust web apps.  The learning curve of these frameworks is much less than Java EE and I will go as far as saying they are more capable because of it.

By using Java, JSP, and Servlets directly on top of a light Model-View-Controller, I believe Java is just as compelling as some of the more popular scripting languages.  Developers need to know they can trim the fat and that there are many advantages to developing in Java, namely because of the next topic…

Dynamic Languages, its all about the VM

It’s all about the JVM stupid!  One of the best features of Java and .NET are the underlying Virtual Machines.  By using JIT compiled VMs, Java code has a distinct advantage over the common interpreted languages such as Perl, Python, and PHP.  In the case of Java, the resultant is even naturally crossplatform.

The really interesting developments here focus on extending the JVM to syntax and paradigms other than the statically typed C++ lookalike.  Clojure and Scala deliver innovative new techniques while Jython and JRuby bring these excellent languages to the Java software platform and virtual machine.

In short, Java provides everyone with a counter to Microsoft’s .NET CLR.  The Java VM has been around the block and tuned by giants such as Sun, IBM, Oracle, SAP and more.

I call on the community to discuss how we can encourage use of the JVM for languages other than Java and build this into a defacto runtime.  Continued tuning and integration with Windows, Mac OS X, and Gnome/KDE *NIX systems is paramount.  Research for easy multi-core development is also worthwhile.  Meanwhile, distributions need to continue packaging the JRE and make it a default.  Individual developers need to be made aware of “Java: The Good Parts” and myths debunked.

Applets, Rich Media, Native Code!?

With the release of Java FX, widespread deployment of the JRE, and better browser integration, Java has set the stage for a comeback to its roots.

During the late ’90s and 2000s, Adobe Flash became the tool of choice for web animation and interactive pages.  It really exploded with the advent of Youtube and other internet streaming sites making use of the Flash video format.  Unfortunately, Flash player is notoriously insecure, resource intensive, and crash-prone.  It is also not widely available for the millions of smartphones that have become more accessible than computers.

Luckily, there seems to be a shift back to the browser with new developments in AJAX, JavaScript, and HTML.  The <video> tag will hopefully make video as easy and portable as graphics are today in the browser.  Clean JavaScript libraries and fast JIT JS engines make it practical to use this paradigm for many domains.

Yet one must acknowledge that somewhere along the line, manipulating a DOM/markup language with a scripting language isn’t the most effective development platform for everything.  Google even thinks it poignant to run x86 machine code in a sandboxed environment in your browser.  I personally fail to see the logic behind this.  Java provides a well evolved, cross-platform solution.   Java can run on your ARM powered Android.  Requiring an x86 CPU just seems like the wrong track in this modern age.  Hopefully JavaFX will pick up the slack and return Java to its roots.  I would love to see the demise of the terrible Flash plugin.

Future and Conclusion

It’s time we considered Java for The Good Parts.

I hope some of my points caused you to reevaluate any bad preconceptions or past experiences you may have had with Java.  Java has undergone great change since its birth and I think it is capable of becoming the premier development platform for applications programming of all types.  Particularly interesting are some of the new languages such as Scala and Clojure.  Java has long been a staple in web development, but has traditionally scared away amateur coders.  If you cut the fat, Servlets and JSP are not much harder to set up than common place scripting languages.  Frameworks such as Grails bring it to parity with Rails or Django.

Java underwent a sea change in 2006 with the releasing of the source code and opening of the development process.  Java and the JVM should be championed by Libre software developers and users alike!

No related posts.

Solr is popular with the enterprise crowd, who love its Java. Being a Java program, Solr includes no shortage of technology whose acronyms contain the letters J and X.

No related posts.