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.
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.
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.
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.
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.
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.
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.
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.