Software Development

Take the Blue Pill and Go Forth

August 4, 2017 by 34 Comments

Forth has a long history of being a popular hacker language. It is simple to bootstrap. It is expressive. It can be a very powerful system. [jephthal] took the excellent Mecrisp Forth and put it on the very inexpensive STM32 “blue pill” board to create a development system that cost about $2. You can see the video below.

If you have thirty minutes, you can see just how easy it is to duplicate his feat. The blue pill board has to be programmed once using an STM32 programmer. After that, you can use most standard Forth words and also use some that can manipulate the low-level microcontroller resources.

Continue reading “Take the Blue Pill and Go Forth” →

Neural Nets in the Browser: Why Not?

August 4, 2017 by 16 Comments

We keep seeing more and more Tensor Flow neural network projects. We also keep seeing more and more things running in the browser. You don’t have to be Mr. Spock to see this one coming. TensorFire runs neural networks in the browser and claims that WebGL allows it to run as quickly as it would on the user’s desktop computer. The main page is a demo that stylizes images, but if you want more detail you’ll probably want to visit the project page, instead. You might also enjoy the video from one of the creators, [Kevin Kwok], below.

TensorFire has two parts: a low-level language for writing massively parallel WebGL shaders that operate on 4D tensors and a high-level library for importing models from Keras or TensorFlow. The authors claim it will work on any GPU and–in some cases–will be actually faster than running native TensorFlow.

Continue reading “Neural Nets in the Browser: Why Not?” →

Linux Fu: Better Bash Scripting

July 21, 2017 by 85 Comments

It is easy to dismiss bash — the typical Linux shell program — as just a command prompt that allows scripting. Bash, however, is a full-blown programming language. I wouldn’t presume to tell you that it is as fast as a compiled C program, but that’s not why it exists. While a lot of people use shell scripts as an analog to a batch file in MSDOS, it can do so much more than that. Contrary to what you might think after a casual glance, it is entirely possible to write scripts that are reliable and robust enough to use in many embedded systems on a Raspberry Pi or similar computer.

I say that because sometimes bash gets a bad reputation. For one thing, it emphasizes ease-of-use. So while it has features that can promote making a robust script, you have to know to turn those features on. Another issue is that a lot of the functionality you’ll use in writing a bash script doesn’t come from bash, it comes from Linux commands (or whatever environment you are using; I’m going to assume some Linux distribution). If those programs do bad things, that isn’t a problem specific to bash.

One other limiting issue to bash is that many people (and I’m one of them) tend to write scripts using constructs that are compatible with older shells. Often times bash can do things better or neater, but we still use the older ways. For example:

Continue reading “Linux Fu: Better Bash Scripting” →

The Site of a Hundred Languages

July 18, 2017 by 32 Comments

Silent film star [Lon Chaney] had the nickname “man of a thousand faces.”  The Try It Out website (tio.run) might well be the site of a hundred languages. Well, in all fairness, they only have 97 “practical” languages, but they do have 172 “recreational languages” but the site of 269 languages doesn’t trip off the tongue, does it? The site lets you run some code in each of those languages from inside your browser.

By the site’s definition, practical languages include things like C, Java, Python, and Perl. There’s also old school stuff like FOCAL-69, Fortran, Algol, and APL. There’s several flavors of assembly and plenty of other choices. On the recreational side, you can find Numberwang, LOLCODE, and quite a few we’ve never heard of.

Continue reading “The Site of a Hundred Languages” →

Using the GPU from JavaScript

July 17, 2017 by 44 Comments

Everyone knows that writing programs that exploit the GPU (Graphics Processing Unit) in your computer’s video card requires special arcane tools, right? Well, thanks to [Matthew Saw], [Fazil Sapuan], and [Cheah Eugene], perhaps not. At a hackathon, they turned out a Javascript library that allows you to create “kernel” functions to execute on the GPU of the target system. There’s a demo available with a benchmark which on our machine sped up a 512×512 calculation by well over five times. You can download the library from the same page. There’s also a GitHub page.

The documentation is a bit sparse but readable. You simply define the function you want to execute and the dimensions of the problem. You can specify one, two, or three dimensions, as suits your problem space. When you execute the associated function it will try to run the kernels on your GPU in parallel. If it can’t, it will still get the right answer, just slowly.

Continue reading “Using the GPU from JavaScript” →

Don’t be a Code Tyrant, Be A Mentor

May 16, 2017 by 168 Comments

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” →

AI Generates Color Palettes; Has Remarkably Good Taste

May 4, 2017 by 27 Comments

Color palettes are key to any sort of visual or graphic design. A designer has to identify a handful of key colours to make a design work, making calls on what’s eye catching or what sets the mood appropriately. One of the problems is that it relies heavily on subjective judgement, rather than any known mathematical formula. There are rules one can apply, but rules can also be artistically broken, so it’s never a simple task. To this end, [Jack Qiao] created colormind.io, a tool that uses neural nets to generate color palettes.

It’s a fun tool – there’s a selection of palettes generated from popular media and sunset photos, as well as the option to generate custom palettes yourself. Colours can be locked so you can iterate around those you like, finding others that match well. The results are impressive – the tool is able to generate palettes that seem to blend rather well. We were unable to force it to generate anything truly garish despite a few attempts!

The blog explains the software behind the curtain. After first experimenting with a type of neural net known as an LSTM, [Jack] found the results too bland. The network was afraid to be wrong, so would choose values very much “in the middle”, leading to muted palettes of browns and greys. After switching to a less accuracy-focused network known as a GAN, the results were better – [Jack] says the network now generates what it believes to be “plausible” palettes. The code has been uploaded to GitHub if you’d like to play around with it yourself.

Check out this primer on neural nets if you’d like to learn more. We’d like to know – how do you pick a palette when starting a project? Let us know in the comments.