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.
It has been quite a while since we updated our readers with the current state of the Mooltipass, the offline password keeper project developed by the Hackaday staff and community.
A few weeks ago we presented you the designs that our mechanical contributors had thought of. We organized a poll to get a feeling of what the favorite designs may be and around one thousand people expressed their opinions. The first three favorite designs with their corresponding votes were:
Continue reading “Developed on Hackaday: the Current Project State”
We know that many of our readers have been impatiently waiting to discover what the Hackaday community-developed offline password keeper project will look like. Today we present you several designs that our mechanical contributors came up with and we will ask you to give your opinion about them. Obviously these are just preliminary cases that may evolve along the way, but we will only produce the electronics for the designs you prefer.
All the designs are embedded after the break, with a multiple-choices poll to express your interest. You may also want to join the Mooltipass Google Group in case you’d want to talk about the designs in more depth or meet their creators. On the firmware side, I just finished soldering many mooltipass prototypes that will be shipped in the coming days to our firmware developers. As you may have noticed, this project is gaining speed!
Continue reading “Developed on Hackaday: The Designs”
It has been a while since we kept you informed about the current state of the Mooltipass project. Well, several days ago we finally received the PCBs we got produced at Seeedstudio. Keep in mind that this first version (shown in the picture above) is only meant to check that the chosen components can suit our needs while our mechanical contributors work on their designs. Moreover, we may add empty footprints for our readers that may want to hack the device.
After a few hours of soldering and a few days of coding, we finally got a basic firmware running. The OLED screen is easily readable and has an amazing contrast (the picture doesn’t do it justice). So far we checked all basic functionalities of the on-board components and it’ll still take a few days/weeks to be certain that we can settle with them. We are therefore starting to ship a few platforms to the firmware developers that want to work on the core functions of the Mooltipass. So if you’re an experienced C developer and have some spare time, you may get onboard by contacting me at mathieu[at]hackaday[dot]com or by joining the Mooltipass Google Group.
In a few days we will publish the designs that our mechanical guys came up with and we’ll ask you to let us know which ones are your favorites. Depending on how things will go, we may produce PCBs for several of them to select our final design based on user experience and ease of use. We look forward to hearing your feedback in the comments section below!
In our Developed on Hackaday series some readers may recall a sentence we wrote: “if one’s idea is not yet in the market, it’s either completely stupid or people are already working on it”. Well, [Josh] casually mentioned that he was also working on an offline password keeper after having recently subscribed to our google group. Similarly to the Hackaday-developed platform, the USBPass is connected to a computer via USB and is detected as an HID keyboard. As you can see in the picture shown above, it uses very few components: an ATMega32U2, a USB connector, three buttons and a few passives chips.
A total of 20 passwords can be stored in the microcontroller’s memory, which can be ‘typed’ by the platform using the push buttons. The USBPass firmware is based around the LUFA USB stack, to which [Josh] added HID report functionality to allow data transfer from his desktop application. The latter uses the Linux/Windows/OS X HID API library so bringing his software to other operating systems can be done in no time. All the project resources can be found on GitHub, while [Josh] is currently working on a B revision which will include an OLED screen.
The Hackaday writers and readers are currently working hand-in-hand on an offline password keeper, the mooltipass (click to see the project description).
Next in our Developed on Hackaday series, we present the first version of our schematics. There’s already been a lot of discussions going on in our dedicated Google group, mainly about the project’s basic functionality. Because our firmware developers wanted to get to work, we decided to send the first version of our hardware into production a few days ago. Before going through the schematics, let’s review the required list of the mooltipass’s core components:
- an easily-readable screen
- a read-protected smart-card
- large flash memory to store the encrypted passwords
- an Arduino-compatible microcontroller with USB connectivity
We’ve been drowning in component suggestions from motivated hobbyists, so we figured we’d make the mooltipass v1 as simple as possible and then move from there. Given this device is developed on Hackaday, we also wanted future users to modify it, building completely new projects based around these main components. Keep reading for our schematics…
Continue reading “Developed on Hackaday: First Version of the Hardware”
We’re pretty sure that most of our readers already know it by now, but we’ll tell you anyway: the Hackaday community (writers and readers) is currently developing an offline password keeper. In the first post of our first DoH series, we introduced the project and called for contributors. In the comments section, we received very interesting feedback as well as many feature suggestions that we detailed in our second write-up. Finally, we organized a poll that allowed everyone to vote on the project’s name.
The results came in: the project’s name will be mooltipass. We originally had thought of ‘multipass’ but [asheets] informed us that Apple and Canon had both applied for this trademark. [Omegacs] then suggested ‘mooltipass’ as an alternative, which we loved even more. A few days ago we set up a google group which is already very active.
An often under-estimated side of a community driven project is its infrastructure and management. (How) can you manage dozens of motivated individuals from all over the globe to work on a common project? How can you keep the community informed of its latest developments?
Continue reading “Developed on Hackaday: Setting Up the Project’s Infrastructure”