Stupid Git Tricks

My apologies if you speak the Queen’s English since that title probably has a whole different meaning to you than I intended. In fact, I’m talking about Git, the version control system. Last time I talked about how the program came to be and offered you a few tutorials. If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git. But even if you aren’t, there are a lot of things you can do with Git that don’t fit the usual mold.

Tracking Documents

Git is really good at tracking changes in documents. If you write plain text files, Markdown, or TeX files, you are in business. However, there is a trick you can use if you use Word, OpenOffice, or many other word processing programs. As a benefit, you’ll even be able to collaborate with others using different programs.

The trick, described in this post and this one, is to configure Git to use a program called Pandoc to convert your input files into Markdown. The Git program can store both, and you can explain to it that differences in the Markdown file correspond to the differences in the document file.

Pandoc is a tool worth knowing about anyway. It converts to and from a dizzying number of formats. If you want to give yourself a headache, you can expand the graphic from their site and try to trace all the lines.

We’ve seen this sort of thing work for collaborative textbooks and even used to track frequently changing documents like French legal codes going back to the time of Napoleon.

Working on a Web Site

You can easily extend the idea of tracking documents to tracking HTML pages for your website. You could just use it as you create and then upload your files like normal. You can also use specialized workflows. Even if you are the sole creator of the site, being able to rewind to what the site looked like last week or last month is often unexpectedly useful.

Managing your Bash Profile or /etc

If you use Linux, you have a lot of files that configure your environment. Things like your .bashrc, .emacs, and so on are hard to keep the same if you use multiple machines. Sure, you can rsync them, but if they ever get messed up, it can be hard to go back and figure out what happened. That’s why I wrote a system for managing this problem using Git. Once it is configured, your machines will automatically pick up any changes you push to the remote host (I keep mine on GitLab). The system is flexible enough to allow for custom configuration per machine and even keep random files in sync for you with just a little setup.

There’s a similar package called etckeeper for keeping track of your system-wide configuration in the /etc directory. You could argue that configuration files are essentially just code, but the intent isn’t coding but keeping version control and synchronization between machines. Also, in the case of etckeeper, there are modifications so Git will store some metadata that is important for that application.

Git as a Database or Bug Tracker

If you are using Git for development, it only makes sense you could use it for tracking bugs, too. In fact, you can use Git as a simple database. Don’t expect to run SQL queries — this just shows a name-value pair system (the proverbial NoSQL database).

Of course, you can store SQLite database (or anything else) in Git. If you do, you can play some tricks like the Pandoc trick for documents to help Git understand your databases better.

Twitter (Yes, Twitter)

Ever wanted a distributed Twitter implementation? Check out Madrox. We aren’t really sure why we want this, but we do.

Text-based Slideshows

Have you ever wanted to show a progression of text screens like a slideshow? Maybe not, but if you did, Git can do that, too. It needs a little help from vim, though.

So…

Even if you never need any of these tricks, some of the methods used to coax Git into doing something unusual might spur you to think of something else. An obvious idea would be a difference program for Gerbers or some other printed circuit board file format. Being able to see what changed between a few revisions of a PC board would be really useful. Obviously, being able to track schematics would be useful, too. Spice models ought to be no problem at all.

Have any useful Git hacks? Leave a link in the comments.

Wrap Your Mind Around Neural Networks

Artificial Intelligence is playing an ever increasing role in the lives of civilized nations, though most citizens probably don’t realize it. It’s now commonplace to speak with a computer when calling a business. Facebook is becoming scary accurate at recognizing faces in uploaded photos. Physical interaction with smart phones is becoming a thing of the past… with Apple’s Siri and Google Speech, it’s slowly but surely becoming easier to simply talk to your phone and tell it what to do than typing or touching an icon. Try this if you haven’t before — if you have an Android phone, say “OK Google”, followed by “Lumos”. It’s magic!

Advertisements for products we’re interested in pop up on our social media accounts as if something is reading our minds. Truth is, something is reading our minds… though it’s hard to pin down exactly what that something is. An advertisement might pop up for something that we want, even though we never realized we wanted it until we see it. This is not coincidental, but stems from an AI algorithm.

At the heart of many of these AI applications lies a process known as Deep Learning. There has been a lot of talk about Deep Learning lately, not only here on Hackaday, but all over the interwebs. And like most things related to AI, it can be a bit complicated and difficult to understand without a strong background in computer science.

If you’re familiar with my quantum theory articles, you’ll know that I like to take complicated subjects, strip away the complication the best I can and explain it in a way that anyone can understand. It is the goal of this article to apply a similar approach to this idea of Deep Learning. If neural networks make you cross-eyed and machine learning gives you nightmares, read on. You’ll see that “Deep Learning” sounds like a daunting subject, but is really just a $20 term used to describe something whose underpinnings are relatively simple.

Continue reading “Wrap Your Mind Around Neural Networks”

Don’t be a Code Tyrant, Be A Mentor

Hardware hacking is a way of life here at Hackaday. We celebrate projects every day with hot glue, duct tape, upcycled parts, and everything in between. It’s open season to hack hardware. Out in the world, for some reason software doesn’t receive the same laissez-faire treatment. “Too many lines in that file” “bad habits” “bad variable names” the comments often rain down. Even the unsafest silliest of projects isn’t safe. Building a robot to shine lasers into a person’s eyes? Better make sure you have less than 500 lines of code per file!

Why is this? What makes readers and commenters hold software to a higher standard than the hardware it happens to be running on? The reasons are many and varied, and it’s a trend I’d like to see stopped.

Software engineering is a relatively young and fast evolving science. Every few months there is a new hot language on the block, with forums, user groups, and articles galore. Even the way software engineers work is constantly changing. Waterfall to agile, V-Model, Spiral model. Even software design methodologies change — from pseudo code to UML to test driven development, the list goes on and on.

Terms like “clean code” get thrown around. It’s not good enough to have software that works. Software must be well commented, maintainable, elegant, and of course, follow the best coding practices. Most of these are good ideas… in the work environment. Work is what a lot of this boils down to. Software engineers have to stay up to date with new trends to be employable.

There is a certain amount of “born again” mentality among professional software developers. Coders generally hate having change forced upon them. But when they find a tool or system they like, they embrace it both professionally, and in their personal projects. Then they’re out spreading the word of this new method or tool; on Reddit, in forums, to anyone who will listen. The classic example of this is, of course, editors like the vi vs emacs debate.

Continue reading “Don’t be a Code Tyrant, Be A Mentor”

How a Hacker Remembers a PIN

If you have more than a few bank cards, door-entry keycodes, or other small numeric passwords to remember, it eventually gets to be a hassle. The worst, for me, is a bank card for a business account that I use once in a blue moon. I probably used it eight times in five years, and then they gave me a new card with a new PIN. Sigh.

Quick, What’s My PIN?

How would a normal person cope with a proliferation of PINs? They’d write down the numbers on a piece of paper and keep it in their wallet. We all know how that ends, right? A lost wallet and multiple empty bank accounts. How would a hacker handle it? Write each number down on the card itself, but encrypted, naturally, with the only unbreakable encryption scheme there is out there: the one-time pad (OTP).

The OTP is an odd duck among encryption methods. They’re meant to be decrypted in your head, but as long as the secret key remains safe, they’re rock solid. If you’ve ever tried to code up the s-boxes and all that adding, shifting, and mixing that goes on with a normal encryption method, OTPs are refreshingly simple. The tradeoff is a “long” key, but an OTP is absolutely perfect for encrypting your PINs.

The first part of this article appears to be the friendly “life-hack” pablum that you’ll get elsewhere, but don’t despair, it’s also a back-door introduction to the OTP. The second half dives into the one-time pad with some deep crypto intuition, some friendly math, and hopefully a convincing argument that writing down your encrypted PINs is the right thing to do. Along the way, I list the three things you can do wrong when implementing an OTP. (And none of them will shock you!) But in the end, my PIN encryption solution will break one of the three, and remain nonetheless sound. Curious yet? Read on.

Continue reading “How a Hacker Remembers a PIN”

A Brief History of Radioactivity

More than one hundred years ago, Henri Becquerel discovered that uranium emitted penetrating rays similar to those used by Wilhelm Röntgen to take the first X-ray image (of his wife’s hand), starting a new era of far-reaching applications. There are of course many dangers that come with the use of radioactivity, but there are also many beneficial uses for our society.

Continue reading “A Brief History of Radioactivity”

IuT ! IoT

Let’s build the Internet of USEFUL Things, not just the Internet of Things. IuT ! IoT

That’s what we’ll be doing over the next five weeks. The second challenge of the 2017 Hackaday Prize begins today. We’re looking for the best ideas we can find for useful connected devices. Twenty entries will recieve $1,000 and move on to the final round to vie for the top prizes ranging from $5,000 to $50,000.

There is no doubt that the future is connected. It has been our future since the advent of the telegraph, and we’re unarguably becoming more connected at a faster rate. The phone in your hand, pocket, or bag connects you to the bulk of human knowledge. But it doesn’t yet connect you to very many “things”. It won’t be that way for long.

Already we’ve seen cameras (security, baby monitor, and everything in between) appear as some of the earliest connected devices, and they’ve brought with them all of the unintended consequences of poorly secured computer gear connected to the wider Internet. At least remote cameras have a purpose; there have been more than enough product launches for things that don’t. Our go-to counter-example is the Internet-connected toaster which is the topic of our wonderful art from Joe Kim this morning. Who needs to toast remotely? Nobody.

Let’s Invent the IoT

Here is our chance to do it right. How can Internet of Things make life better? What things become more meaningful when added to a network and what does that look like? How do we continue to connect our world while safeguarding privacy and being mindful of security. Finding answers to these questions will lead you to Build Something that Matters.

The Surface Area to Volume Ratio or Why Elephants Have Big Ears

There are very few things that are so far reaching across many different disciplines, ranging from biology to engineering, as is the relation of the surface area to the volume of a body. This is not a law, as Newton’s second one, or a theory as Darwin’s evolution theory. But it has consequences in a diverse set of situations. It explains why cells are the size they are, why some animals have a strange morphology, why flour explodes while wheat grains don’t and many other phenomena that we will explore in this article.

Continue reading “The Surface Area to Volume Ratio or Why Elephants Have Big Ears”