In the classic gaming world, even before the NES arrived on the scene, there was no name more ubiquitous than Atari. Their famous 2600 console sold almost as many units as the Nintendo 64, but was released nearly 20 years prior. In many ways, despite making mistakes that led to the video game crash of the early 80s, Atari was the first to make a path in the video game industry. If you want to explore what the era of 8-bit computing was like in the Atari age, a new resource is compiling all kinds of Atari-based projects.
This site has everything, from assembling Atari 8-bit computers based on the 6502 chip, to programming them in BASIC and assembly, to running official and homebrew games on the hardware itself. This was put together by [Jason H. Moore] who grew up around Atari systems and later, their home computers. He even puts his biomedical experience to use here by designing a game for the 2600 called Gene Medic which can be found at the site as well.
If you grew up in the 70s and 80s and are looking for a bit of Atari nostalgia this site is the place to go. It’s even worth a visit from younger folks as well since the 8-bit world is a lot easier to get immersed in and learn the fundamentals of computer science. Of course, if you want to take it the other direction, it’s possible to modify the old Atari to add a few modern conveniences.
Photo via Evan-Amos
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”