Mea Vita: Carpe Diem: software

Showing posts with label software. Show all posts

Friday, September 22, 2023

TypeScript Origins: The Documentary

I watched yesterday’s 80 minute TypeScript documentary, TypeScript Origins: The Documentary. TypeScript is a superset of JavaScript that transpiles, with static typing, into JavaScript so it can run inside a web browser.

The enlightening part of this documentary is that it starts with Microsoft employees talking about what a paradigm shift it was for Microsoft to embrace open source software development. It highlights the differences in leadership between Gates/Ballmer and Satya Nadella who took over as CEO in 2014. Nadella saw the importance and power of goodwill with open source while transitioning the company to providing cloud services. That’s a huge culture shift for a behemoth company like Microsoft which is one of the largest companies in the world.

It’s interesting to see how a company, like Google, has shifted away from, “Don't be evil,” while Microsoft has become more open and supportive of the developer community.

Monday, August 4, 2014

Unable to Decode Playground Data

I've been coding in Xcode's Playground using Swift for the past two months. It seemed that my code was touching on an Xcode edge case causing it to stop evaluating with an error message: "Error running playground. Unable to decode playground data." I can tell where the problem is since the playground sidebar stops displaying output at the line of code that's choking. But I can't tell what the problem is.

The line of code having the problem is a function call at the end of a do..while loop. I initially thought my string manipulation was causing the issue since Swift strings are a little different than the Java NSString that I'm used to in WebObjects.

Narrating One's Work

I figured it might help if I wrote about my issue. Perhaps someone else is having the same problem. A quick Google search shows that a few people are encountering the same issue. But too few are having this problem to find a definitive solution other than chalking it up to an ongoing Xcode bug.

Almost There

I initially thought I had discovered the cause, earlier today, when I changed the half-open range operator to a closed range operator (i.e. I changed ... to ..<). Once I made that change my playground compiled all the way to the end. But this was a short-lived victory when I restarted Xcode and the playground error returned. Toggling between the half-open and closed range operators at least gets my code to compile and run in the playground. So, perhaps I'm getting closer.

Tuesday, April 29, 2014

To Offshore or Not to Offshore at Apple?

When I worked at the Apple Online Store we were organized in teams of six.

My team consisted of four software engineers, one project manager (Scrum Master), and one QA engineer. The QA engineer was a permanent part of our team. He was a white-box tester. We wrote our own unit tests and demonstrated scalability with our component tests while our QA engineer reviewed our logic. He'd look for obvious issues like uncaught null pointer exceptions while digging deeper in search of ambiguous cases like poor security implementations.

New Code Here

Any issues our QA engineer found in our code, during a sprint, were fixed by the software engineers on our team. The rest of the bugs (outside of our recent sprints) were entered into Apple's bug tracking system, Radar. Then, once a week, we'd meet to prioritize bug fixes in Radar. We off-shored the bug fixes to India since it wasn't sexy work. Once it was fixed, we reviewed the code and verified it before integrating it into the main branch.

Bug Fix There

Offshoring bug fixes worked beautifully. Each bug was clearly documented: what really happened vs. what was suppose to happen. I had no idea who was on the other end fixing our bugs but I realized they were intelligent and hard working. However, I could tell they weren't experienced with our technology (WebObjects) or conventions. As one example, I reviewed code where the offshore team had hard coded SQL queries directly into Java. Other times, I saw Java objects instantiated simply to access static Java methods.

The beauty of offshoring a bug fix is we could focus on new feature development.

New Code There

Since offshoring bug fixes worked so well we decided to give them a shot at new development. We quickly discovered that was a mistake. The offshore team didn't have enough context to write good code. Their implementations were too brittle.

This problem frequently happens in any coding organization that's offshoring new development. Without a product roadmap, the offshore team simply writes code to do exactly what you asked for; and no more.

I never saw requirements sent to an offshore team to refactor code. That would be too nebulous of a task. By the time I would have documented all the ins and outs of a refactoring requirement, I could have written the code myself. The real problem is that we don't know how our code will behave until we run it.

And that was the crux of the problem with the code written by the offshore teams I've dealt with. They could only do exactly what you asked for, now, without knowing what was coming. Plus, the requirements had to be very explicit.

Software engineering isn't an event – it's a process. It's a process of continue improvement and refinement. It's iterative.

Tuesday, February 18, 2014

Cache is King in Safari

One trick to speeding up an application is caching. Rather than fetching data from a database or over the network each time you need it, it's better to retrieve the data as soon as possible and hold on to it as long as possible --- and no longer. The only thing worse than slow or no data is bad data.

Autocomplete prefetching over the network before I hit enter.

Last week, I was monitoring a web server log for a URL shortener when I noticed a neat trick Safari does. Rather than waiting for me to hit enter after I typed in a URL, Safari automatically loaded the webpage during the autocomplete phase. It's a brilliantly simple solution. After all, why not start loading a webpage before I ask for it? Actively loading data before it's needed is known as warming up the cache. It's smart since it makes for the best possible user experience (BPUX).

There's nothing like proper optimization, done in small steps, when needed. On the other side of the coin is premature optimization which is the bane of any software engineer's existence. (Rules to Code By)

Another Safari optimization trick I read about but haven't confirmed is that, after loading a web page, Safari will prefetch each link's IP address for faster loading when a user clicks on it since the DNS lookup has already been done.

Anything to speed up my Internet experience is OK by me.

Thursday, March 7, 2013

Don't I Own My Stuff?

Do we really own the stuff that we buy?

This is an interesting question, regardless if we're talking about atoms or bits.

When we purchase content like a movie (DVD, VHS, etc), we can resell that product. This ability lead to a huge movie rental business beginning in the 1980s. So, why didn't the same thing happen with software when it used be distributed on cassettes, floppy disks, CDs, or DVDs? The answer is simple - you never really owned the software. Rather it was licensed to you. (After all, who's never noticed the EULA we all click on, usually without reading it, when installing new software?). Part of the license agreement is that the software is nontransferable.

Although we purchased the software we're installing, we never really owned it anymore than paying for a driver's license gives us the right to own a car. A license only gives us the privilege of using, not owning.

One nice thing about the old days of buying movies or music on disc or tape is that we'd at least have our own copy. We owned the medium, not the content. But, in today's world of downloading content, we don't even own the medium anymore. Throw in digital rights management, better known as DRM, and now access to our purchased content can be impossible if the seller's servers shut down. Imagine if Amazon or Apple went out of business? We'd no longer be able to download our content or authenticate against those servers to enjoy our movies, music, or books. (Realistically, the U.S. Copyright Office, which is part of the Library of Congress, does, from time to time, allow copyright exceptions but it's still a hassle.)

I ran into the problem of no longer having access to my content earlier this week when I tried to download a movie that I had purchased less than a year ago which was stored in the cloud. At first I thought it was a bug, but, in the end, it turned out that the movie was no longer available because its license had been revoked. Now, I no longer had access to, or a copy of, my movie. Live and learn.

Yet, even in the real world, we sometimes don't truly own everything we think we do. Even if you own your home, outright, stop paying your taxes and see who will then own your home.