Everybody knows everything

We’ve developed a really good software practice, agile principle, or whatever you want to call it:

Everybody knows everything.

That is, everybody on the dev team should know all the basic technologies to do anything anywhere in the stack, and understand the overall architecture of the system.

Exception – graphic artists aren’t expected to be programmers, and programmers aren’t expected to be graphic artists, and neither are expected to be help writers.

“Wait”, you’re probably saying, “Doesn’t that consume a lot of time?”

Not really. We’ve spent between 5 and 10 percent of the dev budget doing education.  For a while we did a 2 hour class every friday. At this point we’re not doing them because we’ve run out of topics.

We’ve also got a closely related rule:

At any time a new developer can get started developing without outside help other than making accounts on servers and giving them the repository location.

That is, the development environment’s processes are documented .

Everything you might want to do with our code has instructions in the readme.

Posted in Uncategorized | Leave a comment

OK, once you have boxes of product

The show’s not over when you have boxes of packaged product. The Toucan product was pretty much sitting there in boxes when I came along. But it consumed most of a month’s work to bring it to market:

  1. You have to warehouse it
  2. You have to write up a description, name it, and so on – look at a random similar thing on Amazon – you need to have that same information
  3. You need to have a corporate identity and a bank account
  4. You need to have an online store or shopify shop or etsy shop or whatever you’re going to use. Don’t assume because you’re a software engineer that setting up opencart won’t take time. For the record, I spent a week struggling with OpenCart, then another week writing a shopping cart in SWI-Prolog because I didn’t want to keep struggling with OpenCart.
  5. You need to fill out paperwork to list it on Amazon. This is an amazing bureaucracy.
  6. You’ll need UPC symbols (which you have to buy).
  7. Are you liable if somebody swallows your cool robot?
  8. Did you comply with FCC part 15?  How about CE? Do you need UL listing? Or something else?
  9. If it can be considered a toy, did you have it tested for lead?
  10. Does it comply with RoHS?
  11. How will you export it? The time to figure this out is NOT when you get your first order from Estonia.
  12. Have you done the SEO?
  13. Do you need to collect sales tax?
  14. OK, you’re actually ready to sell them… Now you get to market them.
  15. Remember that facebook page you made once, years ago? Suddenly it’s important.
  16. Hit the streets. Pound shoe leather. Watch Lord of War a few times to get the vibe.
  17. I found this article   50 ways to make your first sale useful, whether or no you have a shopify shop.
  18. Marketing is hard. It’s hard work, and you’ll feel like (and be!) totally operating in the blind.
  19. Now you get to discover that nobody actually wants these things…
Posted in Uncategorized | Leave a comment

Launch! We’re live!

After much struggle and seemingly endless endlessness, we have a product out.

Toucan Laser Baked Color has launched.

Now comes a lot of work promoting, shipping, quality control, and more endlessness.

Posted in Uncategorized | Leave a comment

We didn’t start with flyers

If you’re thinking of doing a startup:

Posted in Uncategorized | Leave a comment

Whats Happening

I’m sorry this is all run together in a single blog post.  I’ve been either too busy, too in the middle of it or not able to talk about it until now.

Last february, while I was working for a social robotics company, I purchased a mobile home I christened the Robohome.

At the time I was thinking about problems of social robotics and perception. So I wrote a paper in which I proposed that lots of Robot behavior problems are actually perceptual limitations.

I was going to try solving the SLAM problem, and surface characterization problem, by applying lots of hardware – basically blanketing the house with kinects.

Well, I left Robokind and this problem became less interesting. But I already had a fair amount of tooling in the house.

Meanwhile, I discovered (that was about a month after moving into the Robohome) that I could afford a decent size industrial laser.  So after a rather incredible amount of hassles getting a Chinese laser imported, one day mid summer a huge plywood box appeared at my door, with a shiny new RECI 6090 80 watt CO2 laser with lift table, rotary attachment, and white sidewalls.

Mid summer I was jobless, and thinking I didn’t really want to return to ‘grunt work’ programming. So I should develop some non coding source of income that would support me. Hey, how about a factory… I could be a manufacturing tycoon… That makes money, I think.

So I bought some woodworking machinery, and set in to make things…. OOoops, porch really isn’t big enough for this activity.  So I start shopping around to rent some shop space.

I’m looking a bit far afield, and find a fellow, Kevin Smolkowski, in Elgin, Oregon, whose dad Al had a laser business. Dad died, and the business has been languishing a bit.  Even more interesting, son is a programmer who works remotely from a corner of the business, and son and dad had turned the place into a sort of private maker space. And so I’m now renting space in the Smoke-Wood facility in lovely downtown Elgin.

Since Elgin’s 350 miles from the Robohome in Sweet Home, I’m just in the middle of an insane time, selling the house, packing, and moving. It’s nutzo.

Posted in Uncategorized | Leave a comment

To make a cardboard hex

People don’t get the complexity of manufacturing even a very simple product in quantity.

Example – I’m making a product for miniatures gamers. It’s pre cut out hexagons cut from corrugated cardboard, with foam rubber ‘grass’ texture on one side. They come 50 in a bag.

Here’s all the steps in making them:

1. source corrugated cardboard

2. determine a good glue – I’ve tried four of them, haven’t found one I like yet

3. buy glue

4. tint the glue

5. buy foam rubber in big sheets (sorry, the little bottles sold for model railroaders would eat my profits up).

6. Dye foam rubber

7. Build gizmo to hold meat grinder bought off ebay and motor to power it

8. put foam rubber through meat grinder

9. apply glue to cardboard

10. spread foam rubber on cardboard. This takes up huge amounts of space waiting to dry.

11. develop custom jig to hold cardboard flat while it’s cut

12. mount cardboard in jig

13. Cut apart with laser

14. After a few of these, dig hexes that have fallen down into pan of laser out

15. source poly bags (stuff like this can drive you crazy – I’ve spent most of a day looking at poly bags)

16. design logo and fold card.

17. print up fold cards. Cut apart with scissors or have it done at copy center

18. fill bag by weight or count

19. fold card over, staple, punch with special hole punch that makes hangy thing

20. Make website, sell on ebay, market on Etsy, etc etc.

21. Keep books and expenses for all this. File various insurance, licenses, taxes, etc.

22. Make product photos

23. When orders come in, copy them from however they come to some other form, probably a manual copy/paste. Source mailing labels, dig them out, put sheet in printer, print out. Source mailer bags. Put product, possibly an invoice/manifest printout, which needs printed, in mailer, put label on mailer, put return label on mailer, take all of them to the post office or fedex or wherever to ship.

And then have customers write you and say “You’re a ripoff – you’re just cutting up cardboard and putting grass on it and selling them, and you want $7 a bag?”

Posted in Uncategorized | Leave a comment

Real World Prolog Usage

This is a repost of a question I answered on StackOverflow. It’s garnered enough attention that I’m reposting it here.


Many study Prolog in college, but I have personally not come in contact with it professionally. The traditional examples given are AI and expert system applications, but what have you used it for and what made Prolog a suitable language for the task?

My answer:

I develop virtual world educational content for a university. The virtual world depends on a lot of web content. For example, we have a system where students can arrange cooperative work groups that is a pretty ‘normal’ looking web application, a quiz maker, some analysis tools, etc.

We have two systems. One we have to use PHP due to bureaucratic insanity. The other we use Prolog. Developing in the Prolog environment is much, much faster for the same programmer on similar tasks.

On the side I’m working on a game that is partially in the virtual world and partially in a web app. The web app is in Prolog.

What do we get from using Prolog?

  1. we get away from the common PHP antipattern of stuffing slow changing data into DB tables. We access data in DB’s by making it look like facts. Massive coding speedup to just be able to backtrack to get all the rows.

  2. Backtracking gives us an ‘automagic’ method of looping over rows when generating HTML from table data.

  3. We forget how much time we, as engineers, spend looking up and/or memorizing API contracts. One predicate often serves as a number of API’s. This massively reduces code size. And massively reducing code size massively reduces work.

  4. I can often truly think declaratively – I find myself making little expert systems everywhere. For example, right now I’m designing a log in/registration system for the game. Because people are interacting partly in the virtual world and partly through the web site, I want them to flexibly be ‘logged on’ as soon as I believe they are who they say they are. I’ve got a little expert system that does it, and I wrote it by defining what ‘logged on’ means. This sort of code, besides often being much, much clearer and much, much shorter, also tends to be bug free. I’m not some superprogrammer, and I frequently write Prolog programs that are bug free when first run (my editor checks for syntax errors).

  5. Metaprogramming – We don’t need no stinkin’ design patterns! A pattern is something you wish could have in the language but you can’t…. leading to the obvious question, why not?

  6. Code isn’t just convertable to data – code IS data. capitol(‘Kansas’, ‘Topeka’).

  7. Schemaless db everywhere. Organize your data structures in an agile manner. More accurately, you don’t have data, you have knowledge. Data just lies there. Knowledge can be reasoned with.

  8. Case based reasoning reduces coupling.

  9. Separation of stateless and stateful programming makes multithreading easier (admittedly, the actual thread support is sorta painful). [10/2012 -Anniepoo – I think that was a reflection of my lack of understanding of the thread model. Since then I’ve come to like the thread model].

  10. Radical destructuring, coding in the head, reduces conditional logic (always a good place for bugs) and makes cases clear. Edge case code tends to end up in separate clauses.

  11. It’s a post object world, away from Java’s ‘now make 7 files cause you have 7 differnet chunks of data’

  12. Good data types – structure as you go is a type, like Lisp lists or Clojure Seqs.

  13. Parsing is a fundamental operation. Nobody’s running around shoving config into xml because there’s no other parser around. No regexes, we have full BNF everywhere (and BNF’s are, imho, far easier to understand).


This answer by Torbjörn Josefsson


Our company (www.intologic.com) mostly uses Prolog.

It’s really good for rule-based systems; a.k.a “business rules”, depending on who you’re talking to🙂

Our end-customers are Ericsson (for ‘building’ sales solutions for their telephone switches etc), and some banks and insurance companies, whom we supply with the tools to evaluate loan applications, make profitability calculations etc.

Our customers like not having to have the logic hidden in hard-coded modules made by a programmer with little or no interest/knowledge about the area in question (like me!).

In fact, we have a graphical tool that allows even non-programmers to draw all the logic rules that are needed. (Drawing done in Visio, and Prolog code is constructed directly from the drawings)

It’s going very well! The site is not very updated or Anglified (we’re swedish), mainly because we get as many customers as we can handle right now. The partner company that supply us with most of our customers are very enthusiastic about the technology, and they are using it for more and more things in their own systems.

We make different interfaces to the rule-engine for different purposes; the desktop and webservice clients are the ones most used, but there is also a web application under development.

The main hassle is the connection to C# and other languages – I wish they had a less archaic way of connecting to the logic engine than sockets, but the version of Prolog we use (Sicstus) is made in C, and has been refined for many years to be brutally efficient at what it does.

Posted in Uncategorized | Tagged | Leave a comment