Homebuilt Computer now “Luggable PC” on Hackaday.io

hackadayioprojectI’ve known about Hackaday for a while, both the professionally curated site hackaday.com and the public participation site hackaday.io. Some of the people behind the site are nearby which allowed me to easily attend some of their local events.

Most of the project pages I browsed through dealt with Arduino boards, Raspberry Pi boards, or even lower-level hardware. I wasn’t sure if a home built PC is the right kind of topic for the site until I brought my current prototype to one of these local meets. The staffers present assured me that it’d be a great project to document on hackaday.io.

All right then! I’ve created a project page to document my work so far, and I’ll continue documenting future iterations over there instead of here.

One of the Hackaday staffers took an interest in the project, wrote up a short blurb and posted it on the curated hackaday.com. I am very flattered by the attention and it was a great opportunity to see how other Hackaday users viewed the project.

The best comments are from people who appreciate the project and had constructive ideas and suggestions – this is what the site promised for project builders and I’m happy to see it working as intended.

There were a few variants of “This isn’t what I want. I want to see…” and while they are good project ideas, they’re not what I’m trying to accomplish here. Maybe they’ll feel inspired by my project to bring their own ideas to life!

And finally, the comments that dismissed the project. Pointing out shortcomings (some fair, some not) as criticisms without offering anything constructive to address the alleged issues. I just shrug off such criticism and focus on my work.

Positive or negative, the overall quality of the comments are far more articulate and intelligent than your average comment on YouTube.

I call that a win for Hackaday.

Homebuilt ATX All-In-One Computer

Scaling upwards from the previous project, I’m moved up from the Mini-ITX board to a (nearly) full sized ATX motherboard. The larger motherboard required a few more fastener locations but was not a significant challenge. The new challenge in this version was the addition of the GPU and properly securing it to the case.


Given the triangular profile of the frame, it took a little effort to design the triangular frame to fasten the GPU metal bracket against. At least, as compared to the normal rectangular computer cases. Thankfully CAD software like Onshape have no fear of trigonometry calculations.


It all works together but I’ve lost most of the size advantage over the standard mid-tower case. Here it is standing in front of the case that used to contain these components.


While the overall volume is still smaller than the generic PC case, it isn’t smaller by a whole lot. Yes, I do incorporate a screen while the standard case does not, but like the standard case I have a lot of unused empty space in my volume. Even though this made cable management easier and neater, a lot of waste is left over.

I decided the previous Mini-ITX version was on the “too small” side, and we’ve overshot into “too large”. The next iteration of this experiment will try to shrink the design and work towards “just right”

The small 3D printed brackets seen on this page were designed in the OnShape project “Easel PC“, which is available as an OnShape Public Document.

Homebuilt All-In-One Mini-ITX Computer

The previous experiment 3D printed just an enclosure for the Mini-ITX motherboard itself, it didn’t have much of a computer around. This project expands on the idea by building something to hold the rest of the computer components.

The physical size is larger than the build volume of the 3D printer so additional hardware were brought into the equation. Emulating the design for some early RepRap 3D printers, I started using commodity hardware store threaded rods as building structure.

The power supply unit is the heaviest single element and employed to provide the stable base. The new addition to the project is the screen built out of the LCD panel salvaged from an old broken laptop. I used a controller board that translated standard VGA/DVI signal to the panel’s proprietary signal to connect the panel to the rest of this system. Such controller boards can be purchased from one of several vendors on eBay.

The cable management is better than the previous effort, which admittedly set a low bar. The PSU is nice and heavy providing a stable base. Compared to the commodity Mini-ITX case: the overall package takes less desktop space (especially considering the screen) and overall roughly the same volume of space.

A better-managed but still a tangle mass of cables.
3D printed all-in-one “Easel PC” with a commodity Mini-ITX case.

This is a perfectly usable (if not very neat or pretty) PC. If this were the final goal, I would take a Dremel cutting wheel to cut off the extraneous ends on the threaded rods. Since I have no real need for a Mini-ITX AIO PC at the moment, though, I’m taking the lessons learned and recycling the metal bits for the next project.

Enclosure for Mini-ITX board

Customized computer cases are an interesting area to explore for 3D printing. The home-built desktop PC market is blessed with the luxury of choice, with a wide selection of components a builder can choose from. As a result of this, most desktop PC cases are wide-open designs capable of taking most combinations of components. This directly proves the old adage: “Jack of all trades, master of none.” In contrast, someone with a home 3D printer can custom design for a specific need built around specific components on hand. The result would be a master of one.

Before I can embark on some grandiose vision, I started with a small project built around the MSI AM1I motherboard. It is an inexpensive and highly integrated PC motherboard on the Mini-ITX standard. It had been installed in a Mini-ITX case that, though smaller than most desktop PC cases, still had a lot of wasted volume present to accommodate for components that I never installed.

Mini-ITX computer with a great deal of wasted volume.

The Mini-ITX standard restricted the motherboard size to 17cm squared, which is convenient because my 3D printer can print up to 20cm squared. This meant I could print something encompassing the ITX dimension in one piece. I pushed for full minimalism resulting in this design available as OnShape public document “Mini-ITX enclosure“.

3D printed Mini-ITX enclosure.

It has screw holes for only the mainboard and the power supply. The large hole on top is tailored for the specific power supply I had on hand, positioning its fan immediately above the motherboard. This allowed removal of the noisy CPU fan as the large power supply fan can pull double duty cooling the whole works resulting in a small neat compact setup.

When I assembled the parts, though, things didn’t look as neat as I imagined:

My, what a tangled nest you have.

I had underestimated the chaotic bundle of wires coming out of the power supply. Most of the wires were completely unnecessary and could be cut if this were the final product, but I didn’t want to do that just for an experiment. The remaining wires could be shortened for such a compact layout, but again I didn’t want to break out the wire clipper and soldering iron for sake of the experiment.

The other item I didn’t account for was the storage device, in this case an old SSD in 2.5″ form factor, awkwardly wedged into a slot. (See the red SATA cable in the picture.) I justified this oversight by the fact that most modern ITX boards have on-board M.2 SSD slots, making a separate mounting bracket unnecessary. Truthfully, though, I forgot.

I had fun building this proof-of-concept with old expendable components in case something went wrong. Next custom PC project will be bigger, with more powerful components, and hopefully the wires will be better managed as well!

Let the App… Materialize!

materializecsslogoAfter I got the Google sign-in working well enough for my Rails practice web app, the first order of business was to build the basic skeleton. This was a great practice exercise to take the pieces I learned in the Ruby on Rails Tutorial sample app and build something of my own design.

The initial pass implemented basic functionality but it didn’t look very appealing. I had focused on the Rails server-side code and left the client-side code simple plain HTML that would have been state-of-the-art in… maybe 1992?

Let’s make it look like something that belongs in 2017.

The Rails tutorial sample app used Bootstrap to improve the appearance and functionality of the client-side interface. I decided to take this opportunity to learn something new instead of doing the same thing. Since I’m using Google Sign-In in this app, I decided to adopt Google’s design concepts to my client-side appearance as well.

Web being the web, I knew I wouldn’t have to start from scratch. I knew about Google’s own Material Lite and thought that would be a good candidate before I learned it had been retired in favor of its successor, Material Components for the web. One of the touted advantages was improved integration with different web platforms. Sadly Rails was not among the platforms with examples ready-to-go.

I looked around for an existing project to help Rails projects adapt Google’s design language, and that’s when I found Materialize: A library that shares many usage patterns with Bootstrap. The style sheets are even written using SASS, native to default Rails apps, making for easy integration. Somebody has done that work and published it as Ruby gem materialize-sass, so all I had to do was add a single line to use Materialize in my app.

Of course I still had to put in the effort to revise all the view files in my web app to pick up Materialize styling and features. That took a few days, and the reward for this effort is a practice web app which no longer look so amateurish.

“Learn Enough Command Line to Be Dangerous” notes

leclThe Ruby on Rails Tutorial was a great way for developers like me to get up and running with no prior Rails experience. However, it does require the reader to have some level of computer software skill so complete beginners could still get lost.

Acknowledging this, the author Michael Hartl has taken on the challenge of getting people up and running in the world of software development under the umbrella of his venture “Learn Enough Society” with a series of titles in the pattern of Learn Enough [X] to Be Dangerous.

I was curious about how his approach, so even though I’m not the target audience I spent some time looking it over.

His idea of starting from Ground Zero is the command line, which I agreed was a fair place to start. The reader is taken through the basics of navigating files and directories and is introduced to some basic command line utilities such as grep.

I applaud the focus on repeatedly prodding the reader to use the man command to learn more information. The manual pages displayed by man were written by programmers for programmers, which meant they tend to be densely packed with jargon difficult to pierce even for experienced users. But that’s where the information is, so one has to dive in to find answers. The tutorial tries to ease readers into man pages by teaching how to search for specific information so the reader is not overwhelmed trying to understand the full text. Baby steps.

Not being the target audience, I can’t judge how effective the tutorial is. I’m sure there are problems that didn’t stand out to me because I already knew the information, almost certainly because it didn’t stand out to the author either.

I did notice one example, though: The tutorial used the computer term argument without explanation. This might cause confusion: “I don’t want to argue with anybody, I just want to learn the command line!” (UPDATE: I e-mailed the author about this observation, and he has added explanations to the tutorial. Very cool.)

The Cost for Security

In the seemingly never-ending bad news of security breaches, a recurring theme is “they knew how to prevent this, but they didn’t.” Usually in the form of editorializing condemning people as penny-pinching misers caring more about their operating cost than the customer.

The accusations may or may not be true, it’s hard to tell without the other side of the story. What’s unarguably true is that security has some cost. Performing encryption obviously takes more work than not doing any! But how expensive is that cost? Reports range wildly anywhere from less than 5% to over 50%, and it likely depends on the specific situations involved as well.

I really had no idea of the cost until I stumbled across the topic in the course of my own Rails self-education project.

I had designed my Rails project with an eye towards security. The Google ID login token is validated against Google certificates, and the resulting ID is salted and hashed for storage. The code for this added security were deceptively minor, as they triggered huge amounts of work behind the scenes!

I started on this investigation because I noticed my Rails test suite ran quite slowly. Running the test suite for the Rails Tutorial sample app, the test framework ran through ~120 assertions per second. My own project test suite ran at a snail’s pace of ~12 assertions/second, 10% of the speed. What’s slowing things down so much? A few hours of experimentation and investigation pointed the finger at the encryption measures.

Obviously security is good for the production environment and should not be altered. However, for the purposes of development & test, I could weaken them because there would be no actual user data to protect. After I made a change to bypass some code and reducing complexity in others, my test suite speed rose to the expected >100 assertions/sec.

Granted, this is only an amateur at work and I’m probably making other mistakes doing security inefficiently. But as a lesson to experience “Security Has A Cost” firsthand it is eye-opening to find a 1000% performance penalty.

For a small practice exercise app like mine, where I only expect a handful of users, this is not a problem. But for a high-traffic site, having to pay ten times the cost would be the difference between making or breaking a business.

While I still don’t agree with the decisions that lead up to security breaches, at least now I have a better idea of the other side of the story.

Protecting User Identity

google-sign-inRecently, web site security breaches have been a frequent topic of mainstream news. The technology is evolving but this chapter of technology has quite some ways to go yet. Learning web frameworks gives me an opportunity to understand the mechanics from web site developer’s perspective.

For my project I decided to use Google Identity platform and let Google engineers take care of identification and authentication. By configuring the Google service to retrieve only basic information, my site never sees the vast majority of personally identifiable information. It never sees the password, name, e-mail address, etc.

All my site ever receives is a string, the Google ID. My site uses it to identify an user account. With the security adage of “what I don’t know, I can’t spill” I thought this was a pretty good setup: The only thing I know is the Google ID, I can’t spill anything else.

Which led to the next question: what’s the worst that can happen with the ID?

I had thought the ID is something Google generated for my web site. More specifically my site’s Client ID. I no longer believe so. A little experimentation (aided by a change in Client ID for the security issue previously documented) led me to now believe it’s possible the Google ID is global across all Google services.

This means if a hacker manages to get a copy of my site’s database of Google ID, they can cross-reference to databases of other compromised web sites. Potentially assembling a larger picture out of small pieces of info.

While I can’t stop using Google ID (I have to have something to identify an user) I can make it more difficult for a hacker to cross-reference my database. I’ve just committed a change to hash the ID before it is stored in the database. Salted with a value that is unique per deployed instance of the app.

Now for a hacker to penetrate the identity of my user, they must do all of the following:

  1. Obtain a copy of the database.
  2. Obtain the hashing salt used by the specific instance of the app which generated that database.
  3. Already have the user’s Google ID, since they won’t get the original ID out of my database of hashed values.

None of which are impossible, but certainly a lot more effort than it would have otherwise taken.

I think this is a worthwhile addition.