Anyone who has done the slightest bit of programming knows about the “Hello, World!” program. It’s the archetypal program that one enters to get a feel for a new language or a new architecture; if you can get a machine to print “Hello, World!” back to you, the rest is just details. But what about teaching kids to program? How does one get toddlers thinking in logical, procedural ways? More particularly, what’s a “Hello, World!” program look like for the pre-literate set?
Those are the sort of questions that led to The Ifs by [Makeroni Labs]. The Ifs are educational toys for teaching kids as young as three the basics of coding. Each If is a colorful plastic cube with a cartoon face and a “personality” that reflects what the block does – some blocks have actuators, some have sensors. The blocks are programmed by placing magnetic tabs on the top representing conditions and actions. A kid might choose to program a block to detect when it’s being shaken, or when the lights come on, and then respond by playing a sound or vibrating. The blocks can communicate with each other too, so that when the condition for one block is satisfied, something happens on another block.
The Ifs look like a lot of fun, and they’re a great jumpstart on the logical thinking skills needed for coders and non-coders alike. We’re not alone in thinking this is a pretty keen project – the judges for this year’s Hackaday Prize selected The Ifs as one of the twenty finalists. Will it win? We’ll find out next week at the 2019 Hackaday Superconference. If you won’t be in Pasadena with us, make sure you tune in to the livestream to watch the announcement.
The ESP8266 is a great processor for a lot of projects needing a small microcontroller and Wi-Fi, all for a reasonable price and in some pretty small form factors. [Simon] used one to build a garage door opener. This project isn’t really about his garage door opener based on a cheap WiFi-enabled chip, though. It’s about the four year process he went through to learn how to develop on these chips, and luckily he wrote a guide that anyone can use so that we don’t make the same mistakes he did.
The guide starts by suggesting which specific products are the easiest to use, and then moves on to some “best practices” for using these devices (with which we can’t argue much), before going through some example code. The most valuable parts of this guide especially for anyone starting out with these chips are the section which details how to get the web server up and running, and the best practices for developing HTML code for the tiny device (hint: develop somewhere else).
[Simon] also makes extensive use of the Chrome developers tools when building the HTML for the ESP. This is a handy trick even outside of ESP8266 development which might be useful for other tasks as well. Even though most of the guide won’t be new to anyone with experience with these boards, there are a few gems within it like this one that might help in other unrelated projects. It’s a good read and goes into a lot of detail about more than just the ESP chips. If you just want to open your garage door, though, you have lots of options.
I was a little surprised to see a news report about Andreas Schleicher, the director of education and skills at OECD — the Organization for Economic Cooperation and Development. Speaking at the World Innovation Summit for Education in Paris, Schleicher thinks that teaching kids to code is a waste of time. In particular, he seems to think that by the time a child today grows up, coding will be obsolete.
I can’t help but think that he might be a little confused. Coding isn’t going away anytime soon. It could, of course, become an even deeper specialty, and thus less generally applicable. But the comments he’s made seem to imply that soon we will just tell smart computers what we want and they will just do that. Somewhat like computers work on Star Trek.
What is more likely is that most people will be able to find specific applications that can do what they want without traditional coding. But someone still has to write something for the foreseeable future. What’s more, if you’ve ever tried to tease requirements out of an end user, you know that you can’t just blurt out anything you want to a computer and expect it to make sense. It isn’t the computer’s fault. People — especially untrained people — don’t always make sense or communicate unambiguously.
Continue reading “Expert Says Don’t Teach Kids To Code”
It’s entirely possible to do your coding in vim or emacs, hammering out hotkeys to drive the interface and bring your code to life. While working in such a way has its charms, it can be confronting to new coders, and that’s before even considering trying to understand command line compiler settings. The greenhorn coder may find themselves more at home in the warm embrace of an IDE, and [morrows_end] has now built one for those working with AVR assembly code.
The IDE goes by the name of Simple AVR IDE, or savr_ide for short. Programmed in C++ with the FLTK widget library, [morrows_end] has tested it on Windows XP, but notes that it should successfully compile for Linux, Unix, and even MacOS too.
All the basic features are there – there’s syntax highlighting, as well as integration with the AVRA assembler and AVRDUDE for programming chips. It’s a tool that could make taking the leap into assembly code just that little bit easier. For another taste of bare metal coding, check out [Ben Jojo]’s discussion of x86 bootloaders.
Anyone who slings code for a living knows the feeling all too well: your code is running fine and dandy one minute, and the next minute is throwing exceptions. You’d swear on a stack of O’Reilly books that you didn’t change anything, but your program stubbornly refuses to agree. Stumped, you turn to the only one who understands you and pour your heart out to a little yellow rubber duck.
When it comes to debugging tools, this digital replacement for the duck on your desk might be even more helpful. Rubber duck decoding, where actually explaining aloud to an inanimate object how you think the code should run, really works. It’s basically a way to get you to see the mistake you made by explaining it to yourself; the duck or whatever – personally, I use a stuffed pig– is just along for the ride. [platisd] took the idea a step further and made his debugging buddy, which he dubs the “Dialectic Ball,” in the form of a Magic 8-Ball fortune teller. A 3D-printed shell has an ATtiny84, an accelerometer, and an LCD screen. To use it, you state your problem, shake it, and read the random suggestion that pops up. The list has some obvious suggestions, like adding diagnostic print statements or refactoring. Some tips are more personal, like talking to your local guru or getting a cup of coffee to get things going again. The list can be customized for your way of thinking. If nothing else, it’ll be a conversation piece on your desk.
If you’re more interested in prognostication than debugging, we have no shortage of Magic 8-Ball builds to choose from. Here’s one in a heart, one that fits in a business card, and even one that drops F-bombs.
Continue reading “Rubber Duck Debugging The Digital Way”
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”
We see projects here all the time that blend computing with the real world. Some people are naturally stronger on the mechanical end of things, whereas some are better with electronics or coding. All three specialities can be needed depending on your project. If your weakness lies in making a computer do your bidding, I might suggest that the Python language is a good one to learn.
I’ve been going through Learn Python the Hard Way, which is offered for free online, or you can pay for it if you so choose. I’ve published my thoughts on lessons 1-10 and 11-20 so far. As a mechanical engineer with limited (but not totally nonexistent) programming skills, it’s been an excellent experience so far.
If you’re wondering if Python is a good language to learn if you’d like to participate in [HAD] style projects, why not check out the following projects featured here:
Or just do a search of [HAD], and you’ll find many other projects for inspiration. If you’ve got a Python project to share, be sure to tell us about it in the comments!