Frank Carver

One of the really great things about the Arduino design is that it is open - all the circuits and board designs are available for anyone to use. One key upshot of this is that once you have done some experiments with something like an Arduino Uno or Mega, and decided on how you want your circuit idea to work, you can easily re-create just the bits you need, in whatever shape suits your project. There are lots of people who have built their own "Arduino" on hand-soldered stripboard or even on a solderless breadboard. Adding extra components and your own wiring is just as easy, and there are plenty of tools to help you design printed circuit boards too.

In short, Ardiuno is not only a fun platform for learning about electronics and programming, but also scales smoothly into real products, if your idea is good enough!

Welcome guys!

I'll admit I have become somewhat obsessed with embedded development recently, so a chance to discuss Arduino and stuff here sounds like fun!

This depends on so many factors. What do you intend to do with it? How much money do you want to spend? Are you comfortable with soldering? Can you wait for a month for shipping from China?

However, most people who are just trying things out tend to opt for a cheap Arduino Uno clone, If you prefer a genuine Ardiuno, the Leonardo might be a better choice - it's a bit cheaper than the Uno and also a bit cleverer. For simple experimentation there is not a lot to choose between the basic Arduino boards, though - they all use the Arduiino development UI and the same "wiring" language for programming, and they are all pretty much compatible with the same extension boards ("shields").

Although you can use Arduino and Raspberry Pi for some of the same kinds of things, they are really very different.

Arduino is best treated as "programmable hardware" - it has a good selection of IO pins and (once programmed) will run its single program whenever switched on. Raspberry Pi, on the other hand is much more like a "proper" computer - it loads an operating system (typically Linux, but others are also availabls) from an SD card, and offers all the screen, keyboard, USB and networking you might expect.

It's also important to remember that both of these are really "product ranges" rather than just single products. Admittedly the range of Raspberry Pis is currently a lot smaller than the range of Arduinos, but there are still three major versions "in the wild". And there are also moves toward an ecosystem of third-party "Raspberry Pi compatibles"

There are so many different types of "arduino" that it's almost impossible to keep track. From the thumbnail-sized DigiStump Digispark to the 32-bit ARM-based Arduino Due and boards with every kind of built-in extra.

And just to add to the fun, don't forget other popular entries in this crowded space such as the Beaglebone Black, Cubieboard, Freescale Freedom boards, and evaluation boards from just about every chip manufacturer!

The "old" 8-bit AVR microcontrollers will certainly still be in use in five years time. It's not so much about new technology as it is about fitness for purpose. There are still people designing and building things with PICs where the expense and complexity of even an AVR is not needed.

The future of the Arduino Due is less certain. It's pretty obvious that there are (and will be) an increasing number of designs using 32-bit ARM cores, but the further along this line you go, the less like hardware and the more like software everything becomes. If you are comfortable with writing code for an ARM CPU there are a lot of options, many of them cheaper than a Due. Raspberry Pi has a huge following; I happen to like the Freescale "freedom" boards a lot, too, but there are hundreds to choose from.

A longish blog post discussing issues with the languages used for Behaviour-Driven Design (BDD) and functional testing.

http://blog.punchbarrel.com/2013/06/13/functional-testing-bdd-and-domain-specific-languages/

TL;DR: functional test specifications using BDD tools look lovely, but hide potential problems which may need significant changes to fix.

Feel free to read the post, comment on it, link to it, and vote it up here ;)

Compared with (for example) Java, ruby is a relatively "low ceremony" language - getting ideas from the bran of a developer to valid Ruby code involves less boilerplate and repetition. Ruby is also dynamically typed, which also helps reduce the amount of type declarations and the size of variable declarations.

Even if you disregard everything else, just this reduction in code size and typing boredom can help make a language more suitable for agile development.

It's a mad meme on twitter, but it's great fun.

Choose a song title, or well-known song lyric, and write it as code in any programming language of your choice.

Examples from early in the meme's progress include:

{ 'name':'Lola', 'occupation':'showgirl', 'fashion':['music','passion'], 'location':[-22.970834, -43.191665] }

and

var i = {shot:{sheriff:true,deputy:false}}

other examples might include:

awk '/^(\w+).*/ { if (desiredLocation($1) != "out there") print "riot" }' <here >prediction

rm rain; cc clearly ~/way/obstacles*

there are plenty more at http://twitter.com/#search?q=%23songsincode and http://songsincodedb.com/post/latest

The fun is twofold. Puzzling out what someone means, and creating your own.

Have you worked out what the ones above are? Found any good ones you want to tell us about? Created any to share with us here?

hole

It certainly looks like the right sort of thing.

HOWEVER, if you are not sure about anything, even just one parameter, then I suggest that you don't experiment with your "very big project". Create a new, much smaller, one with a few files and try it out. Check some stuff in and out, practice merging and so on. Only when you are completely confident that you know what you are doing should you risk screwing up a major project repository.

This is always an interesting conversation. I have had similar discussions in several jobs.

My personal style is to refactor everything within an inch of its life, and ruthlessly remove duplication. I have found, however, that this approach can occasionally increase rather than decrease future maintenance work. The key point for me is not to simply assume that the benefits of separating and factoring everything are always obvious. Or even always valid.

For example. One part of our product has a core section, common to all customers, but each customer also has a "skin", comprising both customer-specific behaviour and look-and-feel templates. A common way to set up for a new customer is to copy the "skin" from an existing customer, then modify it as we learn and agree what the new customer needs. Experience has shown that customer "skins" are usually different enough that attempting to eliminate every duplication and share common aspects between them only ends up costing more development effort to split them apart again when they inevitably differ.

So, here's a strategy to sort this out in your case:

First, find out about the usual development tasks performed by the "copy-n-paste" people. Is their work part of a single growing "core" codebase, or is each piece a separate chunk, perhaps for a separate customer?

Then find out about the people, skills, management and hiring process. Are such developers expected to work together on a core product, or do they work alone on their own bits? Are developers moved about, hired and fired at will, and expected to pick up each small task without understanding the rest of the system? Is the system understandable and self-documenting or is it a ball of confusion?

All of these factors can influence whether refactoring to remove duplication, or duplicating to increase independent clarity is a "survival skill".

Eventually you should find yourself in a position where you can help the organisation realise that duplication suits a small range of circumstances, but refactoring to eliminate duplication (in my experience, at least) suits a much wider range. With that understanding in place, choosing whether to duplicate or refactor can begin to be done based on parts of the system, rather than individual preference.

Does that help at all?

One project where I work right now was split into lots of sub-projects and lots of separate jars as you describe. For many reasons we are now regretting that decision.

Splitting a system into separate projects can make it very clumsy to set up a new development environment, either for a new developer, for a replacement workstation, or just when working on a code branch.

Splitting a system into separate jars is effectively setting the architecture in stone. It becomes hard to refactor and simplify across the boundary between jars, and this makes for a system which grows more complex and "bloaty" over time.

Managing all these separate artefacts can also cause build problems. Not only will it take much longer to build a system, but the more artefacts there are, the more risk is introduced into deployment. Every component and config file potentially needs to contain its own version information, and testing needs to involve every likely combination of versions of every component. This can rapidly lead to an effectively un-testable system and thus introduce problems on the live environment.

In short, working with a single project which produces a single artefact is so much simpler, easier and quicker to work with, and less risky to deploy that I would only consider splitting it where there is no other way.

Please try hard to dissuade your "boss" from this dangerous approach!

If I understand you correctly, using Stringtree JSON it should be as simple as:

JSONWriter jsonWriter = new JSONWriter(); Map values = new LinkedHashMap(); // I assume you can get your option values from somewhere // the following will presumably actually be a loop ... values.put("Alaska", "AK"); values.put("Arizona", "AZ"); ... String json = jsonWriter.write(values);

This should result in a valid JSON string such as:

{'Alaska':'AZ','Arizona':'AZ'}

Is this what you are looking for?

I'm not really clear on what you want to achieve.

Can you explain with an example of what information you have in the server, and how you want it to appear on the browser etc.

Thanks,
Frank.

Naturally enough, I usually recommend Stringtree JSON whenever anyone asks me about Java JSON code. I find it simple, fast, and robust in use.

However, if you do want to step beyond my own software, there is a list of different implementations in a wide range of languages near the bottom of the page at json.org