Tim Habersack

Author: Tim Habersack (page 3 of 20)

Sweden to give tax breaks for repairs

The Swedish government is introducing tax breaks on repairs to everything from bicycles to washing machines so it will no longer make sense to throw out old or broken items and buy new ones.

Source: Article on The Guardian

This is such a great idea! It could be a challenge since some appliances are designed to be throw-a-way, but maybe incentives like this for repair could help some new manufacturers spring up and make some appliances designed to be repaired.

Immersion in Games

I was thinking about immersion in games, and I remembered about one of the first immersive titles I played: Myst.

Now, you can hate or love puzzles, and that’s fine. But you can’t deny the the library in Myst was one of the most amazing things ever.


My older sister and I would sit there, and read these digital books while ‘in’ the library. Some of those books seemed very long, 20+ pages. So we’d be sitting there, and when you’re done reading it goes back on the shelf, then you’re back in the library.

There is something about reading books, or something similar while already IN a game, that makes that game area feel more real. You’ve been there. You’ve read books there.

It’s a really neat effect, and one I want to use in the future.

Trainwrecks; Two Reasons Why Prototyping Ideas is Beneficial

Main photo from versageek.

Like many elements of software design, I feel like I figure certain things out later than my peers. (Thanks Imposter Syndrome!) In this case, I’m talking about the value of prototyping. Of knowing you will be rewriting this code you are making.

For the longest time, forever really, I have been against this. Sure I would make mock-ups of some elements, but I’d never write disposable code. After all, I’ve been doing this long enough that I can avoid all the pitfalls and design an elegant solution after planning. Oh goodness, so much planning. All my well-thought out code would be perfect and I’d never have to change it. THIS NEVER ACTUALLY WOULD HAPPEN.

What actually happens is you paint yourself into a corner, leaving you with tons of refactoring if you need to change directions.

I’m going to give an example of what I mean.

I have been working on Nickelpinch, an open source finance and budgeting web app for a while now. I’ve been making iterations of the basic functionality since 2006. (aaahhh!)

In 2014 I decided to rip it all up, and make an actual, real version other people would want to use. I went with Laravel (a modern framework) because it was the best for PHP, however I didn’t know it very well. So I spent cycles getting up to speed in that. Then I spent lots of time planning the UX/UI and made templates in straight HTML, that I could use later. I started with what the user would start with; account creation and login. I kept going from there.

Hours and hours of time before I got to actually begin implementing my new ideas for handling budgeting and adding a person’s purchases into the system. Once I had that in place, I started testing it all myself. It was bad. Like, super non-intuitive. I kept getting mixed up when using it, and I made it!

There were some design assumptions I’d made that were bad and I had to refactor. Those data models I spent hours on; beautiful structures of normalization? All had to be modified. Which meant all my user functions needed to be altered everywhere, etc. It was a huge time sync.

I’m almost done now (yay!), but I ended up wasting lots of time. (Boo)

If I had made a shaky prototype, no concept of user accounts, sign ups, etc just a test of the core of the app, I would have seen the flaws. I would have saved at least 80 hours too. :/

So there is reason #1 for making prototypes:

It will save you time over all, especially if you have UX elements.

Another reason, and this one just came to me several days ago, is what I call pre-fatigue. It’s when I think of an idea for an app or game, and I see the roadmap ahead of me and it’s so long I despair and do not even start. I’ll explain via another example.

I am designing a sci-fi game, something akin to a turn-based 2D Elite. I want MMO support, I want mobile and system apps for it, I have an ambitious design with lots of untried gameplay methods, etc. Here is what I was planning, from a technological standpoint:

  • Core Game Logic in Go, which would be my API
    • Go is great for this, because it’s crazy, crazy fast, BUT it is more C-like and it takes longer to develop in than some scripting languages
    • I have never used Go, will need to learn it. Huge time investment.
  • Game Client in melonJS, a lightweight HTML5 / JavaScript game framework
    • This would be a mostly empty UX/UI shell that the API would shove content into.
    • I am fairly familiar with JS, but this is a huge step in complexity for me. Another huge time investment.

Just looking at that bums me out. It’s a ton of work and lots of that stack I need to learn. Also, my biggest fear; what if, after all that foundation is in place the core game or UI doesn’t work well? Shoving all those really good intuitive warnings aside, I started..

I started learning Go, and dove into galaxy generation. I actually made modest progress at this, see my totally working script. It’s so fast!

Then I realized, well what if people want to play single player? Having one huge chuck of game logic in Go for the API, and duplicating it in JS would be a nightmare.. I know! I should write the API in JS too, and learn yet another tool, node.js for my server-side JS API.

At this point you should be screaming “Just stop it, stop!”. But I didn’t stop. I rewrote my galaxy generation + some basic UI elements in pure JS (That means no frameworks or helpers, since I wanted to up my JS skills). This took a while, but I ended up making JS-Space, which is pretty neat.

However, he farther I was getting into the UI elements, the more I was beginning to despair. “What if I spend 40 hours getting this component working, just to totally toss it?”. So I stopped development.

I basically have been at this spot for 10 months. Then! I had the thought, “Dude, just make a single player tech demo of the combat. JUST that to start.” I saw I was making the same mistake I made with Nickelpinch; building the entire city infrastructure before seeing if it was a viable location.

What a difference it’s made to my outlook! Instead of toiling away for years on something before I have anything to show for it, I could have something a little nifty in maybe 2-3 months! Suddenly I am full of energy to tackle this!

That is the second takeaway:

Small prototypes give you something to show for your work, and you get that morale boost of having something to show for your time spent.

So if you are starting a project that has a lot of untested elements, just make tiny tests of each of those. Don’t worry about ANYTHING other than testing that one thing. Get all your untested theories tested, see how they really feel when using them, THEN go back and make it the right way.

Announcing JS Space!

I am so excited to share this with you!

From the README:

JS-Space a tool/game that will generate a mostly-realistic galaxy from a seed, then let you navigate around it to view the various stars within the galaxy. It’s designed to work well on computers and mobile devices.

How to Use:

  • Use the arrow keys on screen, or on your keyboard to navigate about the galaxy.
  • Click/tap on a star to view it’s details.


Some Neato Features

  • It’s Open Source!
  • Only vanilla JS was used, no jQuery or anything else.
  • Alter the config.json to change the number of sectors that are generated, min distance between generated stars, etc.
  • The Sector View window is calibrated on page load, so on your phone try loading it in portrait vs landscape mode to see different layouts.
  • All the star details are mostly realistic main sequence type stars, with appropriate percent chance of existing. (Class M are much more common than class A, for example.)
  • You can pass in a seed via the URI. For example: https://js-space.graviton.systems/?seed=reverse_the_polarity . Otherwise it uses the default seed.
  • No images are used, it’s all done via CSS and/or HTML Canvas elements
  • The entire payload of this is less than 25kb! (when accounting for gzip)

Here is how it looks on a mobile device:


Why Did you build this?!

A great question. 🙂 Initially I wanted to make a MMO 2D Space game. I still want to do that, but after working on this early prototype, I am convinced I don’t want to do it in JS. Still, I learned a lot from this and definitely upgraded my JS skills.

Do you plan on developing it any farther?

I am thinking about adding the System View, so after you click on a star, you can also view the system of planets surrounding the star, click to get their info, etc.

Should I trash my old i18n project or revamp it?

So, three years ago I created a project called Lemon-Filling. From the repos readme:

Lemon-filling is a tool to build i18n support into your small to medium-sized application. With Lemon-filling, you can create terms, define those terms in various locales, and group terms together into pages. Via MySQL query in your application, ask for a page, specify the locale you desire, and all terms on that page will be returned. Comes with web-based admin area to create and manage your localized content.

At the time, it seemed to make sense, and I wanted a tool so I could add internationalization to my web apps. I used the tools I knew to build it. Also, I think the grouping of terms by the ‘page’ they are on had merit.

However, having a separate DB for storing all the language of a project and having to have an extra query on every page load now seems excessive. A better approach would be to poll then cache some JSON of all the language needed for the app. I just thought of that, and dang that makes this more useful..

Anyway, the admin interface was built on top of CodeIgniter 2.1.3, which, thanks to PHP becoming a better and better language, has some errors now on every page load. Also, the repo on github has no stars or anything; as far as I can tell no one uses it.

There is some basic work that would need to be done in order for it to get working again, and no one (including me) is using it right now. Should I just delete the repo?

I do like my modified use I described above, and caching all the web apps language in some JSON. However, I don’t really have a burning desire to do this. Also, there would need to be work done to actually make this a thing that can be easily pulled into other projects.

Oh snap. This could be a free service for open source projects. I could see that being really helpful. I will spec out my idea, and float it out to several i18n groups and see if it would even be something they’d want to try/use.

Olderposts Newerposts

Copyright © 2018 Tim Habersack

Theme by Anders NorenUp ↑