I have loved this hymn since I first heard it twenty years ago, when I came into the church. We always sang it in an up-tempo way, but many versions on YouTube are slow and warbling and kind of lame. Well, fear not … the boys of Flatfoot 56 (a Christian Celtic Punk band out of Chicago) have produced the most rocking version of I’ll Fly Away that I have ever heard. Enjoy!
(One from the archives. Written 25th February 2005. I think it still stands.)
While talking to a few of my co-workers, I mentioned my personal definition of job security and they liked it so much that I thought that I’d share it here as well, in the hope that it can equip someone else to be prepared for unexpected unemployment. The real definition of:
Job security is being able to get another job tomorrow, not still having the same job tomorrow.
It is an unfortunate fact that companies have an uncanny knack to get themselves in a pickle and then turn around and release workers to ease the cashflow. There’s nothing we can do about their tendencies, but we certainly can prepare for such a scenario. I feel that each of us bears a responsibility to be prepared for such an occasion.
As a geek, I take time (lots of time, actually) to keep my skills up to date with the latest and greatest techniques, platforms and programming languages. It doesn’t matter to me if the current instance of my Benevolent Employer doesn’t like technology A or programming language B. If I feel that they are worthwhile and that knowledge of it will benefit me, then I’m going to learn it. I did it with Java back in the 1.0 days, Struts in the 1.0 days and now I’m doing it with Ruby and Rails. None of these decisions have been guided by the ol’ Benevolent Employer, but they’re not responsible for my career anyway. I am responsible for my career, so I’ll choose what to learn and the timetable that I want to learn it in.
This is the price I choose to pay to be very good at what I do and, as a very useful by-product of that, to be very employable. I have no idea how many evenings I’ve stayed up late after the Queen of All She Surveys and the little princesses have gone to bed, or gotten up early on a Saturday morning when I’d much rather have enjoyed sleeping in, to learn new technologies. As a friend of mine used to say, “Do you want to be better or bitter?” I choose to seek to be better.
A classic spiritual tune sensitively delivered by Eric Clapton.
A perky offering this time. Dave Edmunds takes the already energetic Sabre Dance by Aram Khachaturian and turns it up to eleven.
An interesting meme that gets thrown around frequently is that men need to be in touch with their feminine side. This is a feminist trope that is both wrong and unhelpful. The inference is that men are unbalanced when they are being manly and that it would be better if they would behave more like women. If this was true, would not it be logical for the same people to also direct women to get in touch with their masculine side? Of course it would, but you never hear this voiced to women. The entire responsibility is placed upon the men to behave more like women.
The reason that women are not told to get in touch with their masculine side is that women know that they don’t have a masculine side. It’s very simple. women know they don’t have one, so they know that it would be pointless to suggest such a thing to other women. And for the record, guys also know that women don’t have a masculine side so we know better than to suggest it. Besides, we like women being feminine, so why would we want to change that?
You never hear guys (manly ones, anyway) telling each other that they need to get in touch with their feminine side. This is because we know that we possess no such thing. Men don’t have a feminine side. And that’s alright, because the ladies don’t have a masculine side either. The good Lord made us men to be 100% masculine and that’s how we operate best. We are entirely unlike women once you get past the basic similarities of having the same number of arms and legs. We act and think in masculine patterns.
Certainly we have a few things that have become traditionally thought of as the prerogative of the females of our species. Men, contrary to rumor, do have emotions. We just like to keep them tucked away and distinctly dislike bring them out when there are witnesses to see them. Every couple of years we might retreat to a quiet place of solitude and dust off our emotions to check that they’re still there, but other than that, we’ll stick to logic thank you very much. Most guys are more sensitive than ladies suspect. Nah, just kidding. Well, sometimes we notice things, but we stay quiet about them until we figure out if the ladies in our lives are unhappy about them.
So, guys don’t have a feminine side and quite frankly we’re perfectly fine with that. To be fair, we’re also perfectly fine with you ladies not having a masculine side either. Let your husband keep being manly and you keep being ladylike and it’ll all work out fine.
A nice acoustic guitar version of AC/DC’s Thunderstruck by Luca Stricagnoli.
One of my enduring technical heroes is Robert C. Martin. Mr. Martin is one of the lucky few in the technology world who are instantly recognizable by either their initials or their first names. Robert C. Martin is known as “Uncle Bob”. I was fortunate to be able to meet Uncle Bob in the Chicago area at a one day free seminar given by ObjectMentor, back in 2001. At the end of the day, I asked if I could have my picture taken with him and he was very kind and generous and immediately said yes and even insisted that we be standing in front of their “Star Trek wall”.
Thank you Uncle Bob for your kindness to a young and star-struck fan. I continue to read your writings and still aspire to your level of software craftsmanship.
I was an early adopter of Palm mobile devices. Yet, like most technology, they had their day in the sun and then were cast into the shade of the next generation of mobile organizers and then smart phones came along and made pretty much everything else obsolete.
This morning, I noticed this charger lying around and actually stopped to take a look at it, thinking I could swipe it for an at work USB charger. It was a charger for my last Palm device. I’m pretty sure that I no longer have the device, so the charger is off to the circular file. If you look carefully at the picture, you’ll notice the proprietary connector. I’m so glad that the days of proprietary chargers are on the way out. Apple are one of the few holdouts, but even they are moving towards USB-C for their laptop charging technology.
TL;DR – Technically no, but practically yes.
Java is interesting, in that it is both a programming language and a runtime environment. When Java first burst upon the scene, it was promoted as a general-purpose cross-platform programming language. It was not the first language to make such a claim, but it was the first to live up to most of its hype. I was a very early adopter of Java and remember the joy of writing code on a Windows PC and then having my tester run that exact same code on their Apple Mac. I’d used scripting languages that could do that, but never anything that needed compiling. I was hooked.
Java achieves this cross-platform behavior by using a runtime environment that is compiled for each target environment. This is known as the Java Virtual Machine, or JVM to its friends. Any operating system that has a JVM can run Java code unchanged. Java wasn’t the first language to use this approach. Other languages were intended to be able to be easily ported. C is perhaps the canonical example of this, being intended to allow the Unix operating system to be ported to other different architectures. The Pascal language compiled to p-code which was then run by the Pascal runner. But, for all of this, there had never been any emphasis on taking this to the next level and making languages runnable cross-platform.
Making Java cross-platform took a special form of dedication by the good folks at Sun Microsystems. It didn’t hurt that they didn’t realize they were writing a general-purpose programming language. At the time the language was being developed, it was intended to be targeted at embedded software development. The target for Java (back then called “Oak”) programs was consumer electronics, anything from toasters to set top boxes for controlling TVs. Consumer electronics are massively price sensitive and it is not unusual for the target CPU in a device to be changed during the project if another CPU becomes available cheaper. Sun Microsystems addressed this by designing the JVM to hide the physical CPU and all hardware access under the covers. Effectively, the JVM becomes a virtual CPU on top of the physical CPU, with its machine code instructions commonly called bytecode. This way the programmers did not need to worry about the physical hardware in the device and could program it against the unchanging environment of the JVM. Similarly the hardware team could utilize anything they wished, or that was cheap, without fear of upsetting the programmers as long as the JVM could be made to run on it. And given that the JVM was written in pure C, just like the highly portable Unix operating system and used all of the portability experience that came from porting Unix, it turned out to be fairly straight-forward to get the JVM running on almost any platform.
In the end, Java was not used for consumer electronics, but was instead released as a general-purpose programming language. Its heritage of extreme portability shone through and Java became the first successfully cross-platform compiled programming language.
A consequence of the emphasis that Java was both a programming language and a runtime environment had an interesting effect. Programming language designers have targeted the JVM for the compiled executables from their languages. To this end, there are over a hundred different languages that are either written specifically for the JVM or that have the JVM as one of their available compilation targets. A number of these languages have become quite successful in their own right. Groovy, Scala and Clojure come to mind easily. These languages are very different from Java, but all run natively, by design, on the JVM. Groovy looks like someone merged a Ruby interpreter into the Java compiler, Scala is an object-functional language and Clojure is a powerful and highly functional Lisp that is now popular with some of the biggest names in the Java ecosystem.
Within the Java runtime system, code written in different languages may be used together. As long as a portion of code targeted for the JVM follows all of the standard calling and naming conventions, any other bytecode can call it as simply as any pure Java code. You can have a Scala program calling Groovy utilities that use Java objects and a Clojure library. And with the Java Native Interface (JNI) you can even call compiled native code on the platform you’re running on if you have a very specific need.
With all of this interoperability, it seems clear to me that the Java ecosystem is vibrant and powerful. There are many different languages available that can work and coexist in harmony. With this perspective, it is clear that Java (speaking of both the language and ecosystem as a whole) is not a monoculture.
And yet, within large corporations, Java feels exactly like a monoculture. Let’s look at why this is.
Java’s place and role in large corporations today is very different from how it was nearly 19 years ago when I first started using it. Java was a brand new programming language. It was untested as a business language. But it did have some intriguing promises of platform portability and a certain amount of initial respect afforded it because it came from Sun Microsystems. The early adopters all tried it out and enough of them decided it was worth continuing with, that they started sneaking it into their workplaces.
Java had not yet come to the attention of managers, so asking to use it was unlikely to work. Programmers instead, did what programmers have always done, and they started using it anyway. I started using Java at a previous employer without any managers knowing. My supervisor knew, but no managers. And my project was a success, so now Java is an approved technology there. While it seems hard to imagine, Java was not the business programming language of choice for several years after its release. Even after a year or two, it was still necessary to present arguments as to why your project should use Java. This is completely opposite to how Java is perceived by businesses now. Unless you work at an all Microsoft shop, a university or a startup, there’s a really good chance that you’ll not only be working in Java, but that you were mandated to work in Java.
Once businesses embraced Java, they immediately started trying to quash all creativity out of their Java programmers. Not out of any malicious ill will, but because they felt that they needed to standardize their use of it. Specific versions of Java were mandated, coding standards were often written and enforced, specific IDEs were required to be used. Some companies even prohibited any use of free or open source software libraries or utilities. Everything had to be standard and approved.
This condition has not changed much since those early days. Companies still mandate the version of Java that may be used, the brand and version of application server and every library that you may wish to use in your application still needs to be approved first. These standards do get updated, but generally at glacial speeds. I recently took a two year sabbatical from programming to work as a full-time pastor. Before that sabbatical, most companies were using Java 6, upon return I found that they were still using Java 6 despite Java 9 being in the public stages of being released.
And this is why I believe that Java is a de facto monoculture. Corporations are so determined to standardize everything (for the sensible and noble purpose of reducing risk) that they slow themselves down and reduce their ability to take advantage of new technical advancements. These missed opportunities span a range from new versions of programming languages they’re already using to new languages, techniques or paradigms. Should a large corporation be using these new languages and paradigms? Maybe or maybe not, but the problem is not whether they should use them, but that because of their own risk-averse behavior, they can’t use them!