60% Custom Apple Mechanical Keyboard Build

Since I type on a vintage Apple AEK M0115 board every day, I can attest that the 60% custom board with the cut-down steel plate, vintage orange switches and vintage PBT keycaps feels exactly like typing on the M0115. I’m super happy to have the same experience on a modern form factor that I can slip in my backpack and take on the road!

I started using computers in the golden age of keyboards — which in my opinion is from about 1985 until 1995. To this day, if I’m considering a new computer, the first thing I do is some touch typing on the keyboard. If I don’t like the keyboard, I really won’t go any further. Since 1995 I’ve actually liked very few newly made keyboards, sad to say.

I understand most people aren’t that picky about keyboards, but since I spend so much time typing (10+ hours a day), I’m picky. Unreasonably so…

I love old mechanical switch keyboards, and I type on them every day. I have a collection of favorites…Among them an IBM Model M, a Northgate Omnikey Ultra, and every mechanical keyboard Apple made for the Macintosh line. But my “daily driver” is an Apple AEK (M0115) made circa 1987 that I restored to “better than new” condition. Here is this beast of a keyboard:

I love this board, but I have to admit, it’s just enormous! It takes up loads of space, and my mouse is a mile away from the keyboard’s home row…which I don’t like at all and is just a bit annoying to me. But the sound and the feel — just amazing.

Quest for the Perfect Board

The perfect keyboard has until now alluded me…I love the mechanical keyboards made in the 80s/90s…the feel, the sound, the precision…but I like modern, compact form factors which are just more practical. I mean…do we really need function keys? Do I really need a 10-key on the right side? I understand why most people want dedicated arrow keys, but with thoughtfully designed Fn-overlays even dedicated arrow keys aren’t really necessary.

Hooray!

Finally, thanks to a custom PCB I ran across on Geekhack, called the Alps64, I saw that I could have the best of both worlds — 1990s mechanicals (and nostalgia!), 2017 form factors, and complete customization.

The catch is…I’d have to build it myself.

A note on customization

For those who use any kind of laptop keyboard, you have a “Fn” key, that allows certain keys to have more than one function. For example, a MacBook has an F1 key that is used to dim the screen, or if you press Fn-F1, it acts as the actual F1 key. That’s an “overlay”.

The Alps64 has seven possible overlays, and is fully user-programmable using the TMK Keymap Editor. Seven is way too many, but the point is if you want to have more than one “Fn Layer”, go for it (I use two).

Build Objective

The objectives for building my perfect keyboard were:

  1. 60% form factor (having 60 keys, no nav cluster and no keypad)
  2. Alps keyswitches — I prefer both “tactile” Orange made by Alps in the 1980s, Blue Alps or White (either Alps SKCM or Matias clones). I’ll mention my inability to choose between these later…
  3. PBT Keycaps with Apple Macintosh legends having that Univers Condensed Thin italic font that they haven’t used in ages.
  4. Key layout matching the 1987 Apple Extended Keyboard M0115
  5. Fully user programmable keys and layers

I like the 60% layout because:

  1. The amount of desk space it needs — barely any at all.
  2. Keeping the mouse within two inches of the Return key on the keyboard is simply better ergonomically. I find that leaning over to my mouse/trackpad makes my shoulder and elbow ache after a few hours.
  3. 60% is the only keyboard size you can realistically toss into a backpack and take anywhere.

Which switches? All of the above!

After much internal debate, I decided I’d never be able to choose whether to build this board with tactile (orange) or clicky (blue/white) switches…so I decided to build bothof them. Plus I built a third with Alps Cream Dampened switches, which I don’t enjoy typing on as much, but are a bit more considerate to use in a shared work environment, library etc. — especially around poor souls who grew up with rubber dome keyboards that make barely any noise at all.

Bill of materials

  1. PCBs from Hasu’s Geekhack project. These are custom made and shipped from Japan. Luckily I got in on a group buy drop in January, and had these parts in February. In the meantime, I had to start sourcing vintage boards to use as donors for the other parts.
  2. Alps Orange Switches. I actually have three M0115 AEK boards that could have donated the switches…but since I think the M0115 is the best board Apple ever made (and is somewhat rare), I couldn’t bring myself to sacrifice any of them. So I found an Apple Standard Keyboard (M0116) in poor overall condition (i.e. really cheap to acquire), but with good switches. Check.
  3. Blue Alps Switches. Blue Alps switches are very rare (and ridiculously expensive when found), but they are the best clicky alps switches, and this project needed only the best. It took months, but I finally was able to source a 1987 Ortek keyboard in HORRIBLE condition, but with Blue Switches. A third of the 104 switches are not working very well but I only needed 60 good ones, which I was able to find in that board.
  4. Plates. Apple AEK II (M3501) boards donated plates. I didn’t feel the same hesitation as I did about the M0115. The M3501 boards are plentiful and cheap, and I easily found them in “non-restore-worthy” condition to use as donors for steel plates.
  5. Keycaps. The AEK IIs that donated their plates also donated their keycaps.
  6. Cases. The new boards would need cases. Since I’m really looking for these boards to be a 60% version of the old AEK models, I went with plastic since the old vintage boards also use plastic cases. I used Sentraq plastic 60% cases, which worked out perfectly.

Preparing Parts

  • The PBT keycaps don’t yellow, and just needed a good scrub in the kitchen sink to remove 30 years of grime. I find using something like Comet or Soft Scrub to (gently) scrub away grime and shine restores the caps really well.
  • The ABS plastic space bar definitely yellows, and on a 30 year old board the space bar color will be closer to orange than gray. I Retrobrighted the spacebar with a UV LED Bulb and 12% Cream Hydrogen Peroxide. Color back to normal! There are several techniques for Retrobright — I use the process developed by 8-bit guy described in this youtube video.
  • To restore the switches, I disassembled them completely, blew out the dust with canned air, lubricated the sliders and springs (tip: a thin coat of SuperLube added to the Alps switch coil springs eliminates “ping” sound if it bothers you)
  • In this photo the restored switches and keycaps are bagged and the plate is removed from the M3501 keyboard and cleaned, but obviously is still the wrong size for a 60% board.

Cutting the plate

I really was going for the same feel and sound as the original M0115 AEK, so I cut the original plate down. This actually went really fast with a zip saw and a bench clamp.

After the zip saw, I used a bench grinding wheel to finish the shape, knock off the sharp edges and any surface rust. Then to finish up I re-painted it satin black with a Rust-Oleum spray.

Assembling the board

Fast forwarding a bit…the Alps64 as delivered needs to have diodes soldered in to every switch position, and then of course the switches are installed in the steel plate and soldered to the PCB. Actually, I found installing the diodes took longer than installing switches. But both operations are simple, and anyone with patience can handle this level of soldering.

Here’s the front of the Orange switch board after all soldering is completed.

And the back-side of the board

Once the soldering was completed, I ran a quick test by connecting the raw board to my laptop and check that all the keys register as expected. Afterward, it’s time to load up keycaps, mount the board in the case, and customize the firmware.

A fortunate aspect of cutting down the vintage steel plate is that all the stabilizer hardware is on-hand and correct — all parts are just going back into the same plate they came from.

And loading keycaps on the Blue Alps Switch board.

And here’s the board installed into the Sentraq case, running through final tests on my laptop.

And finally, the family of three keyboards Blue Alps, Orange Alps, Cream Dampened Alps

Firmware Programming

Like most of the custom PCBs out there, this board is “programmed” using a web-based GUI Keymap Editor. This couldn’t be simpler…you point and click to choose what each key does, then download a binary file to flash onto the keyboard using a DFU utility. That might seem a little techie, but if you can handle soldering, flashing firmware is within grasp.

The DFU utility was pre-compiled for Windows, but not for macOS, so rather than compile my own from source code, I downloaded the Windows version in a Parallels VM, attached the keyboard to the VM, and flashed it that way. That worked fine.

Results

Since I type on a vintage Apple AEK M0115 board every day, I can attest that the 60% custom board with the cut-down steel plate, vintage orange switches and vintage PBT keycaps feels exactly like typing on the M0115. I’m super happy to have the same experience on a modern form factor that I can slip in my backpack and take on the road!

There’s really no direct comparison for the board with Matias Click switches — Apple never made an AEK (or any board that I know of) with Clicky White Alps switches. I can compare the 60% Matias Click board with my AEK II that I retrofitted with Alps SKCM click switches (harvested from a non-working Omnikey). The Matias board feels very similar, maybe a little louder and has a little more ping (coil spring vibration) than the AEK with the Alps white keys from the OmniKey board. But it’s very satisfying to type on, and I really love it.

Overall, I’m delighted with the outcome of this project, and can’t thank Hasu enough for going through the trouble to design and manufacture the AEK layout compatible PCB boards that made these builds possible!

Is HTML5/JavaScript a Mobile Development Silver Bullet?

Mobile development today has a serious dilemma: on one hand we can’t create the best user experience without designing and coding for each targeted form factor. On the other hand we usually don’t have the budget or staff to start from scratch developing a unique application for each new device we’d like to target.

Mobile development today has a serious dilemma: on one hand we can’t create the best user experience without designing and coding for each targeted form factor. On the other hand we usually don’t have the budget or staff to start from scratch developing a unique application for each new device we’d like to target.

HTML5/JavaScript to the Rescue

One potential solution to the dilemma is to develop apps in a common markup/script language that will be correctly reformatted by each device’s built-in web browser, and then wrap the resulting app in a native app container. Today the most common implementation of this approach is to use HTML5/JavaScript solutions like PhoneGap, KendoUI, Sencha or other similar solutions. Most of these toolkits draw core technologies from Cordova, which used to be known by the name PhoneGap, which is now a specific implementation of Cordova, the base technology formerly named PhoneGap. If this point confuses you, this blog post may help.

But HTML5/JavaScript isn’t really a silver bullet solution to the mobile dilemma — it’s merely an optimization choice. HTML5/JavaScript mobile app proponents claim the approach eliminates duplication of development effort with no degradation of user experience or performance. In fact the strategy only partially delivers on these promises, and introduces new compromises. Whether the compromises are acceptable depends on the nature of the application and external constraints such as budget and engineering skills available in the development team.

For developers already proficient with HTML5 and JavaScript, the technology is an obvious way to side-step learning curves and deliver cross-platform applications at the same time. For mobile applications that are essentially tools for consumption of article-based content, HTML5 may indeed be an excellent choice since that content is designed with an HTML web browser in mind anyway.

Yet HTML5/JavaScript isn’t always successful. FaceBook famously discarded its HTML5/JavaScript mobile app implementations to start over with native applications after users were dissatisfied with the user experience. Others have encountered significant and unexpected challenges using HTML5/JavaScript as the complexity of their applications increased.

Write Once Run Everywhere

For as long as users have had a choice among competing computing platforms there have been developers working out how to deliver cross-platform software efficiently. Time will tell whether HTML5/JavaScript will have the same problems other Write-once-run-everywhere approaches have had for the last 40 years, or if it will be the unifying technology that finally solves the cross-platform cost vs. user experience dilemma.

Where to from here?

It remains to be seen what will be the typical implementation strategy for most mobile apps 2–3 years from now. Will most applications be developed on the dominant ecosystems using an ecosystem-provided Universal App capability on each? Will HTML5/JavaScript evolve, eliminate all of its current limitations and become the first truly successful write-once-run-everywhere architecture? Or will a third party like Xamarin provide a proprietary solution to create native apps on any ecosystem without the traditional “lowest common denominator” limitations?


Originally published at rekerrsive.ghost.io on April 20, 2015.

Should you use a backend-as-a-service for your enterprise mobile app?

Whether you’re creating a mobile solution for internal (enterprise) use, or a consumer-facing B2C app, one of the fundamental architecture questions you need to ask is whether to build your mobile back-end from scratch on your own — or use a mobile backend-as-a-service (MBaaS) provider.

Whether you’re creating a mobile solution for internal (enterprise) use, or a consumer-facing B2C app, one of the fundamental architecture questions you need to ask is whether to build your mobile back-end from scratch on your own — or use a mobile backend-as-a-service (MBaaS) provider.

Why do mobile apps need back-ends?

A few types of apps don’t need a “backend” — for example, a calculator app is self-contained and needs no back-end at all. But most apps depend on backend services of some kind. Backend services provide essential functionality to many mobile apps:

  • Storing preferences in a central location so users have consistent experiences on different devices
  • Storing documents in a central location to enable collaboration with other users
  • Displaying information and media not deployed with the app
  • Processing transactions (e.g. purchases, orders, communications)

Most users don’t think about web service layers underneath their favorite apps, but users do expect applications to be responsive. Backend services need to be scalable, reliable and able to deliver sub-second responses to many concurrent users.

Build your own backend or use a backend service platform?

In the mid-1990s, when the Internet was young, it was common for companies to build their web site using internal web servers racked in their own data centers. Hosting services weren’t yet ubiquitous, and web sites were built and managed much like any other business application.

Today it’s less common for a company build its website from scratch and host it on-site. Content management systems are now the standard building block for a web site, and external hosting providers generally provide higher levels of scalability and availability than most in-house data centers could at a fraction of the cost.

Backend services for Internet-connected mobile devices is beginning to follow the same pattern — even for enterprise applications. Backend services scratch-built as general-purpose web sites are giving way to specialized mobile backend service architectures. Much like web services, mobile backend services can be purchased and used on-premises, or built entirely on public cloud infrastructures in a platform-as-a-service (PaaS) model, or architected using a hybrid approach that blends both internal and cloud-hosted components.

Choosing the Right Option for your Project

As mobile services become more in demand, many providers are rushing into this crowded space. MBaaS offerings are available in an array of architectures — each one suitable for a different kind of application. Would your project be better served by a platform provider’s MBaaS offering, or by an MBaaS provider with a tightly integrated application development tool? Or something in between?

Understanding the different MBaaS segments is the first step in finding the best match for your requirements. Let’s consider the general categories.

General Purpose Cloud Platform Providers

If you’re an enterprise with a strong IT-led software design competency, the most comfortable fit may well be your cloud platform provider of choice. These providers include (but are not limited to):

  • Microsoft Azure Mobile Services
  • IBM BlueMix
  • Amazon Mobile Services (AWS)
  • SalesForce’s Salesforce1

These types of MBaaS providers offer mobile services as a part of a larger suite of offerings. They can provide not only mobile backend services, but other types of application services that can be leveraged as well to build large, comprehensive enterprise architectures.

If you have broader IT architectures to build along with your mobile project, a general-purpose provider with a strong MBaaS on offer may be an obvious choice. But even if you don’t need a broad platform today, the stability and future-proofing you get by using an experienced platform vendor are appealing.

On the downside, platform providers provide broad platforms that can be more complex to understand and learn to use. This shouldn’t be too surprising — platforms that have more knobs to turn, give more control to the application developer, and have more ways to meet the same requirements inherently have a steeper learning curve.

Mobile-Centric MBaaS Providers

If your primary goal is to support your mobile app — and particularly if it’s a narrowly-targeted consumer focused app — you might first consider a cloud provider that’s narrowly focused on its MBaaS offering. Examples of these include:

  • Parse (recently acquired by Facebook)
  • Kinvey
  • FeedHenry (recently acquired by RedHat)

There are advantages to using a provider like these. These providers are more focused on providing MBaaS services as their core product, whereas platform providers typically offer MBaaS as a feature of their overall portfolio offering. Developers without enterprise application experience may find that the more narrow product focus of these MBaaS providers leads to a lower learning curve for them.

On the other hand, mobile-centric MBaaS providers may not provide as much flexibility as a larger platform provider. For example, a mobile-centric provider may not provide a SQL-based relational database as part of the platform. Large, general-purpose platform providers like the ones typically would provide such an offering within their overall platform — as well as Internet of Things (IoT), Big Data/Hadoop, and cloud-based virtual machines that could be provisioned to support application requirements.

When looking at specialized MBaaS providers, bear in mind that they can be quite narrowly focused on specific mobile app segments. For example, Parse is more focused on delivering consumer apps, while FeedHenry is much more focused on the needs of internal enterprise applications.

As a final note of caution: the narrowly-focused MBaaS space has been recently characterized by frequent acquisition announcements. A few of these acquisitions have led to services being completely discontinued (perhaps the acquisition was to acquire engineers — not customers?).

Since your iOS or Android code will include APIs specific to your MBaaS provider, the last thing you want to do is migrate to a new provider on a forced deadline after an unexpected acquisition. In this regard, a general-purpose platform provider may provide more stability and predictability of long-term support.

Application Building Platforms

Each of the previous two providers types generally offer MBaaS services provisioned as web service layers to your application — but you still build your own application using whatever development tools you choose. This might be XCode for iOS, Java for Android, C# for Windows or PhoneGap for an HTML5 solution. You then use the MBaaS provider’s APIs to connect your application to their backend service layer.

App Building Platforms go much further, and provide not only the web service and data layers, but also a complete application development environment. These providers usually promise tools that let you code an application once (typically in JavaScript) and deploy it to all devices (either by cross-compiling to native applications or by running an HTML 5 app in a proprietary container). This approach promises tighter end-to-end integration between the front-end development and back-end development as well as higher levels of developer productivity.

On the other hand, using an App Building Platform to build and host your application would seem to provide the highest degree of vendor lock-in. Moving your application away from a proprietary development environment — should you ever decide to — would likely be a far more significant re-engineering effort than switching from one platform provider’s MBaaS layer to a new one’s.

Providers that provide this type of full application development and application hosting services include:

  • Appcelerator
  • Telerik
  • Host it Yourself

All of the MBaaS providers in the previous three categories focus on providing public cloud services to back-end customer applications. Some have no built-in facilities to integrate with on-premises services (e.g. Parse), while others have a fully-developed tooling to build hybrid cloud/on-premises architectures (e.g. IBM). What if you want a mobile backend, but for whatever reason none of it should be deployed in a public cloud?

Predictably, there are alternatives for enterprises that want or need to build and deploy their mobile infrastructures entirely on-premises. Some examples include:

  • IBM MobileFirst
  • Built.io
  • Kinvey

I previously listed two of these three providers above in the public cloud segments. In fact all three of these providers offer both on-premises and cloud offerings. The converse is not true, however. Most cloud-based MBaaS providers do not offer on-premises deployment solutions. So, if you know you must deploy on-premises, your options will be fewer (though still excellent!). Always know your constraints before selecting your technology!

Why use a mobile backend platform for on-premises deployment? Why not just crack open your favorite development IDE and build it yourself? The answer revolves around the trade-off between building every nut and bolt in your application stack — or using pre-built components as a way to avoid building and supporting so much complex code yourself.

Using a pre-built stack like IBM MobileFirst provides application deployment and monitoring, as well as pre-built web service integrations for all major platforms — right out of the box. Buying a backend service platform provides a lever to get a solution deployed faster and with higher quality than a completely build-from-scratch development strategy.

As always, deploying on-premises software involves higher up-front capital investment, requires more sophisticated infrastructure support resources in-house (or contracted from an external provider), and more hardware and network investment than cloud provisioning. Yet depending on how application partitioning, information security requirements and service dependencies fall, on-premises may be the best (or only) alternative when considering a mobile application deployment strategy.


Originally published at rekerrsive.ghost.io on February 8, 2015.