Mea Vita: Carpe Diem: java

Showing posts with label java. Show all posts

Monday, September 4, 2023

Everything They Wanted to Be

Java became what Ada wanted to be. Write once, run everywhere.

Javascript became what Java applets wanted to be. Mobile code in a web browser.

REST became what SOAP wanted to be. Remote procedure calls with data over the Web.

JSON became what XML wanted to be. Human readable, machine to machine data exchange.

Saturday, December 29, 2018

Dave Winer posted a lesson-learned tip about JavaScript. Although Java and JavaScript are unrelated languages, they have many similarities.

var d1 = new Date ("March 12, 1994");
var d2 = new Date ("March 12, 1994");
alert (d1 == d2); // false

It seems that JavaScript, like Java, is actually comparing the two Date objects, d1 and d2, to see if they're the same object in memory, not the same value. Since these instance variables are not referencing the same object the alert line of code returns false.

Although, at first blush, this seems unintuitive, it actually allows greater flexibility when making comparisons. If you don't want to compare the two objects, but rather the value of the two objects, then you can simply send the Date object the getTime() message which returns true.

var d1 = new Date ("March 12, 1994");
var d2 = new Date ("March 12, 1994");
alert (d1.getTime() == d2.getTime()); // true

And, finally, to prove my theory to myself...
var d1 = new Date ("March 12, 1994");
var d2 = d1;
alert (d1 == d2); // true

Thursday, April 26, 2018

Apple's Language Holy War

In the late 1990s, we used to joke about language holy wars at Apple. Apple had purchased NeXT, in December 1996, for WebObjects and the NeXTSTEP operating system (which became Mac OS X and was recently rebranded as macOS). Since NeXTSTEP's release, in the late 1980s, the OS was built on Objective-C (a superset of ANSI C that was object oriented [OO]). In the mid-1990s, Java came along, from Sun Microsystem, and it quickly became the first, mainstream, OO language leading to a holy war between Objective–C and Java.

WebObjects was originally written in Objective-C, but, by WebObjects version 3.5, in 1997, it was fully bridged with Java using the cheekily named JOBS (Java to Objective-C Bridging Specification). A WebObjects developer could write code in Java and most every Java object had a corresponding Objective-C object wrapped and running in the background.

Java vs. Objective-C

Around WWDC 2000 or 2001, Apple settled the holy war by stating that Objective-C would be used on the client (Cocoa desktop development) and Java would be used on the server (WebObjects server development). But we'd still argue about the pros and cons of the two languages.

The strength of Java was that it was a strongly typed language. The strength of Objective-C was that it was a weakly typed language. So, the pros and cons were subjective. It really depended on your needs. Objective-C would let a developer "touch the metal" meaning a developer could write code to interact with a computer's low level memory. This is very powerful, but it requires a lot of responsibility on the software developer's part since they'd have to manually manage their program's memory usage by using pointer arithmetic. Pointer arithmetic allows a developer to directly touch values in the memory of a computer. If the developer makes a miscalculation, such as terminating a string incorrectly, it could cause the program to crash.

The selling point of Java, which was very similar to Objective-C, is that it didn't use memory pointers. Instead, Java code ran inside a virtual machine that acted like a sandbox between the executable code and the operating system. Since Java couldn't directly touch computer memory, it used references instead of pointers. The big joke in Java was, if you tried to call a method on an instance variable that was null, you'd throw a NullPointerException, which was a poor choice for an exception class name since Java didn't have pointers. That message class should have been NullReferenceException. An excellent solution for avoiding these bugs, called optionals (option types), has been implemented in Apple's Swift programming language, three years ago. But I digress.

Since Java ran inside a virtual machine, it was a little more complicated to talk directly to the OS. For example, if you needed to access the computer's file system then you probably shouldn't hard code something like "c:/ProgramFiles/tmp" since that wouldn't work if your Java code ran on a Mac (c:/ is the path to the main hard drive on a Windows computer, whereas macOS doesn't care about the physically drive, but, rather, the medium being accessed with a path like "/Volumes/Macintosh HD/Users/jmoreno/tmp."

Since the path to a file or folder (directory) on each OS was different, it required the software developer to use global variables that the Java virtual machine populated when it started up (on Windows, it's "c:/" and on macOS it's "/Volumes/Macintosh HD."

Not hard coding OS paths requires a bit of discipline, but it keeps the software developer honest and prepared if their code needs to run on a different OS than was originally intended. This type of discipline was key, in 2005, when Apple switched the Macintosh CPU from IBM's PowerPC chip to Intel's CPU. Without the public realizing it, Steve Jobs announced that Apple had been secretly developing Mac OS X for both CPUs and the time had come for Apple to switch to the same CPU that Windows ran on. This had the side effect of allowing Windows to run natively on a Mac using Apple's Boot Camp utility software.

Code Reviews

I have written a lot of sloppy code, in my time, and I discovered that group code reviews, weekly or biweekly, were a great help. This was the place where we could show off our code to the rest of our team; and the rest of the team could question anyone on the code they wrote. Most teams usually don't go out of their way to review someone else's code if it works as expected. Typically, it's not until a particular software developer has left a team when someone else has to read and review the departed team member's code. This can raise a lot of questions as to what the original purpose of the code was.

Good coding practices and discipline will pay dividends years down the road, so take the time to do it right. If not now, then when?

Monday, August 28, 2017

My Favorite Technical Hacks

Hacks are simple shortcuts that increase productivity. They can be inelegant, but they solve a problem quickly. Hacks may be brittle, solving a problem under specific conditions, or they can require a few extra steps to realize the effective solution. An ideal hack is an innovation or design pattern that works so well it becomes a feature. My favorite non-technical hack (life hack) is one I use after hunting for a parking spot when they're scarce. In the past, I've parked my car and rushed off to my destination without paying attention to where I parked. This has happened to me a couple time in La Jolla and Pacific Beach. So, one life hack I use to remember where I've parked is to open up the Maps app on my iPhone and take a screen shot as soon as I am parked.

I've come across a few computer hacks that stick out in my mind. Computer hacks are harder to explain than life hacks because one has to have an interest in software engineering. But, here goes...

1. Preventing JPG "Theft"

Java was the hot new language when I first started working at Apple. In order to get up to speed I coded as much Java as I could, especially applets since that seemed to be the future of the Web. (It turns out that Java became everything Ada wanted to be, and JavaScript became everything that Java applets wanted to be.)

One area that I focused on was coming up with a way to prevent JPG images from being "stolen" from a webpage. Once an image is displayed on a screen (computer, smartphone, etc), there's no simple way to keep someone from taking a screen shot. My Java applet solution got around this by taking the thumbnail of the image and blowing it up to the full size image so that it was pixelated (blurry). Then, as the user moused over the image in the applet, a small portion would come into focus. This allowed the user to see the entire image at full resolution, but only in parts (one-sixteenth, to be exact). While it was possible to take 16 screen shots and piece them together into a single, full resolution image, that was far from practical.

The full size image was encrypted on the web server to keep a user from downloading it directly from the server. The encrypted image was then sent to the user's web browser and decrypted in pieces, while in memory, inside the client's applet as they moused over the image.

2. Facebook encrypted UDP

Awhile back, I heard about a brilliantly simple trick that Facebook uses to speed up their site. When a Facebook user logs into their account, their data is fetched from a database. While fetching the data, the user has to wait. The amount of wait time could be imperceptible to the user, or it could be a noticeably long time if the website is under a heavy load. "Heavy load" is a relative term, but Facebook serves more than two billion active users per month, so saving any amount of time makes a noticeable difference at that scale.

Wouldn't it be great if Facebook's servers knew what data a user needed before the user formally requested it? Well, that's effectively what Facebook's done with their little trick that simply involves sending an encrypted UDP (datagram) ahead of the formal TCP/IP request. UDP requests are fire-and-forget, meaning there's a small chance they might not arrive at their destination, but, if they do arrive (and they usually do) then they'll reach Facebook's servers sooner than a TCP/IP request. There's more overhead with TCP/IP since it guarantees delivery (or notice of a failed delivery). TCP/IP is the reason that webpages render perfectly compared to the BBS's of the 1980s that used unreliable dial-up modems where static and interference would be misinterpreted as data and displayed as garbled text.

So, the UDP datagram arrives ahead of the TCP/IP request which enables Facebook's servers to pre-fetch the data and load it in its cache before the formal TCP/IP request arrives. This hack is a simple, yet elegant, way to optimize a website for speed simply by "priming the pump."

3. Safari DNS and Pre-loading

DNS: Safari speeds up webpage load times by looking at all the host names on a webpage, once it's loaded, and then performing a DNS lookup. This saves time, later, when a user clicks on a link since the DNS lookup has already been completed. The time savings might go unnoticed or it can save a few seconds. (There's even an HTML tag to help DNS prefetching.)

Pre-loading: Although I haven't read about this hack, I noticed it when I was monitoring my web server's logs in real-time. As I started typing my own domain name in Safari it came up with an autocomplete suggestion before I finished typing. At the exact moment that the autocomplete suggestion came up in Safari, I noticed an http request for that autocomplete suggestion hitting my web server and showing up in my web server logs. In other words, Safari was loading a webpage before I hit enter. There's not much harm in doing this even if I never formally requested that URL. This is why some webpages load in a flash, especially when I'm on a fast Internet connection and the web server is using a content deliver network (CDN) like Akamai or CloudFront.

4. Keeping iOS Apps Running in the Background

For nearly four years I lead the San Diego Kickstarter Meetup where I mentored entrepreneurs on crowdfunding their products. (At one point, we had six live crowdfunding campaigns.) A couple of the entrepreneurs had iOS apps that accompanied their product which needed to continue running in the background; but iOS doesn't like to keep an app running in the background because it drains the battery. One of the most interesting hacks to keep an app running in the background was to simply play a silent MP3 file which kept the app "alive," even when it was in the background. The downside was that you couldn't play music from another app, but for some situations that was fine.

5. Timestamping Race Photos

In the late 1990s, I started going to races (5Ks, 10Ks, marathons, etc), snapping race photos at the finish line, and then selling them either at the race or online. The challenge was finding a runner's photo among thousands – bib numbers had to be entered manually, which would take many hours. I came up with a solution that worked great which, to my surprise, no other race photography had implemented. (Nowadays, RFID chips attached to the racer's running shoes solves this problem.)

My solution was to simply synchronize the time on my digital camera to the race clock where midnight (00:00 on a 24 hour clock) was the start of the race. If a runner finished a race in 23 minutes and 30 seconds then they could simply start looking for their race photo around 00:23:15 (23 minutes and 15 seconds after midnight) since the photos were taken about ten seconds before the runner crossed the finish line.

Not all hacking is bad. 🖥