As computers became more popular in the late 80s and into the 90s, they vastly changed their environments. Of course the technological changes were obvious, but plenty of other things changed to accommodate this new technology as well. For example, furniture started to include design elements to accommodate the desktop computer, with pass-through ports in the back of the desks to facilitate cable management. While these are less common features now there are plenty of desks still have them, this 3D printed design modernizes them in a simple yet revolutionary way.
While these ports may have originally hosted thick VGA cables, parallel printer cables (if they would fit), and other now-obsolete wiring, modern technology uses simpler, smaller solutions. This doesn’t mean that they aren’t any less in need of management, though. This print was designed to hold these smaller wires such as laptop chargers, phone chargers, and other USB cables inside the port. A cap on the top of the print keeps everything hidden until it is lifted by hand, where a cable can be selected and pulled up to the top of the desk.
While it might seem like a simple project at first, the elegance of this solution demonstrates excellent use of design principles and a knack for integrating slightly older design decisions with modern technology. If you have a 3D printer and a cable management port on your desk, the print is available on Thingiverse. Not every project needs a complicated solution to solve a problem, like this automatic solar tracker we recently saw which uses no complicated electronics or algorithms to reliably point itself at the sun.
A bunch of people who share a large workshop and meet on a regular basis to do projects and get some input. A place where kids can learn to build robots instead of becoming robots. A little community-driven factory, or just a lair for hackers. The world needs more of these spaces, and every hackerspace, makerspace or fab lab has its very own way of making it work. Nevertheless, when and if problems and challenges show up – they are always the same – almost stereotypically, so avoid some of the pitfalls and make use of the learnings from almost a decade of makerspacing to get it just right. Let’s take a look at just what it takes to get one of these spaces up and running well.
Continue reading “How To Set Up And Run A Makerspace” →
The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.
The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:
foo = 0;
– 79 characters line length as a soft requirement
– 4 spaces, no tabs
Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.
The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?
We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.