Kaali

Abstractions need proper names and meaning. In this example the "abstracted" version would be a lot simpler if the names of the functions would be 'doB()', 'doC()' etc. and it is still hard to make sense of as A, B, C, D, E as an example doesn't really have an obvious meaning. Just an order. But if the main function describes a process that must happen in a specific order, then by all means keep the code in the single function if it makes it more clear.

Monadic error handling is quite nice for domain specific errors, but for exceptional situations which are not supposed to happen, you still need some sort of an exception system. And even with domain error conditions, exceptions has a nice property of saving a stack trace, which can make error hunting a bit simpler.

In Finland we call it "kissanhäntä" (cat's tail) or "miukumauku". "Miu" and "mau" are actually cat's meows, so "miukumauku" is kind of a "a meow, a meow" with two different words.

Nowadays it's usually called "ät-merkki" as in "at-sign" as "at" is spelled in Finnish.

Unity is the most popular engine at the moment. Saying that it is the best is going a bit far. I actually think that Unity is one of the best 2D engines available. For 3D the tools are really broken for production use, and Unity is quite unresponsive about fixing them. And the renderer quality is a bit of a far cry from CryEngine or Unreal Engine, but is getting there bit by bit. Except that those two are also progressing, mostly by doing actual new research in the field.

Still, new 2D engines are welcome as Unity still has the 3D package to work with in a 2D game.

True. I shouldn't have been that dismissive about React. My comment was really related to the explosion in popularity of client side rendered static websites. And React happens to be one of the more popular ways to implement them.

This is a great example of a modern looking website, that actually performs in a way one would expect from today's computers and browser optimizations. Instead it seems to be more important for developers to use the coolest new technology, even though it actually hurts the end-users.

React is all the hype right now. And it is a nice system for creating dynamic single page apps. But there is little reason to use it for static websites, which could be cached easily, instead of rerendering the website on the client with Javascript. And instead of having automatically cached static website, we use local storage and such to get something resembling a cache.

I would love to see some mechanical sympathy in modern web development, instead of cargo culting all the new tech.

There are women in the calendar.

Node.js is in an interesting position. There is a lot of libraries and new ones are coming out at breakneck speeds. It's also a way for frontend developers to transition to backend tasks. And it gets a lot of mindshare at the moment, with MongoDB and microservices.

But in my opinion a lot of Node.js ecosystem is a lot of mismarketed features. Many developers doing backend services with Node.js actually think that it's the fastest thing available, even though multiple benchmarks, e.g. techempower, shows that it really isn't. And even more people seem to think that it is a way to do simple parallellism, so they won't have to understand threads and locking, which are really complicated stuff. But as many have said here, Node.js does not support threads, or parallelism without running multiple different processes. Which can be fine if you don't have any shared state between your processes. And with no parallelism in process, it is quite easy to actually block the event loop by running anything that is CPU and not IO bound. This can be a loop that is too long, too much math, or even parsing a JSON string without using streams. All of these can block the event loop, which means that no requests are going through that process while one request is parsin a JSON.

And even though there is a lot of libraries and frameworks for it. The quality is often really, really bad. As in invalid MD5 algorithm bad, etc. But there are also some gems such as Bluebird for promises, which makes the callback hell more easier to handle.

You will also face immature debug support, profiling and static analysis. You barely get any refactoring help from your tools, even though IntelliJ IDEA does quite a good job with basic refactoring and debugging. And you will have to spend time with handling odd bugs with no logs showing up on crash, or stuck processes when something has gone really wrong in the code, with no way of knowing (if you don't have DTrace) where the code is stuck.

But there are stuff Node.js seems to excel at. It is really quick for creating a simple REST service, feedback loop is really quick as the services restart almost immediately (at least when you don't use all the latest ES6 transpilers). And if you want to create isomorphic applications, where the server can render a Javascript site on behalf of the browser for the first request, or even successive requests for mobile use, there is no better platform than Node.js. And if you know that you will not do anything that is CPU bound, just IO bound stuff, you can still use any library available. Where for example in Java or Python, you would have to find specific libraries that support your chosen async IO framework.

I would use Node.js between a backend server done in a more robust ecosystem such as JVM, and the browser. Where Node.js gets the data from the backend and does it's magic with isomorphic React for the client.

Accessibility is a point I didn't think about at all. Thanks for reminding me, it's really something that is all too often forgotten. JavaFX supports ARIA and all standard controls have accessibility built-in. But I have no expertise to actually comment on the quality of accessibility features in JavaFX.

Apple has started doing something about energy efficiency, probably because most of their computers are laptops where energy use is quite important. OSX tracks energy efficiency, which somehow calculates how much power a single application uses (CPU + GPU if I remember correctly). But I don't think they do anything with that info at the moment.

I guess it would be a nice incentive for developers if OSX could notify you that an app that is on background is using a lot of energy at the moment, maybe even with a quit-button when on battery power. At least I wouldn't want my app to end up on that kind of a popup.

There are some okayish cross platform frameworks, such as QT and even JavaFX. One of the main complaints of cross platform GUI's has been that they don't work like native applications. But for some reason nobody cares when the app works like a single page web app, which in many cases is a lot worse than even plain old Swing apps. Which at least supports right-click properly.

I think the main reason that node-webkit and what-not are popular, is because of web developers moving to native app development. It's really easy to get started that way, and you can even share code with your web app. Where something like QT has a really huge learning curve for programmers transitioning from Javascript.

About poor algorithms. I actually worked on optimizing a well known web browser for a couple of years. And most of the stuff we did, was because of really bad Javascript code. Even though it seems gluttonous to embed a web browser in applications, and even insecure, it doesn't have to be as bad as it is, especially with a simple application like Spotify. This is going on a bit of a tangent, but every frontend programmer should at least learn how the browser actually works, a nice site for that is http://jankfree.org/

There is another side of extra resource use that I don't really see addressed except in the mobile space: ecology.

Even though my computer can run all applications without a hitch, it is still very wasteful to constantly use CPU power because of technology choices or plain laziness. As an example, Spotify and Slack are two applications that seem to use most of my CPU after Chrome. Spotify and Slack combined seems to hover around 5-15% of total CPU (a two year old i7). When there is a lot of traffic in Slack I have seen it using 15-20% by itself, with multiple processes running and memory use going above 200 megs.

Both applications work smoothly, but should they really use that much resources? A chat application? A music player? With modern CPU's I would expect them to be at the bottom of the process list when sorted by CPU usage. I used IRC on my Pentium 75Mhz and it ran fine. When simple applications are made so poorly that they use that much resources, what is the worldwide impact of that power use? And what about the users that don't have powerful and expensive CPU's?

It seems that usually when moving from paper to digital forms, the original form is just reimplemented to be filled out on a computer. Where rethinking the actual process might actually reduce the actual interaction that is required from a person, to an automated system which can induce information that would otherwise be filled manually.

In Finland when filling your tax forms online, the form comes prefilled with numbers that are calculated from your tax info of the previous year. If there are no changes in your salary or benefits, you can just agree to the the form and it is done, without typing out anything.

Tactile controls are something that most phones are missing. But there seems to be a problem of culture. The games developed for mobile phones are targeted at mainstream casual markets. And there is also a culture of free beer with mobile gamers. When the client won't pay a proper price for the game, it is too much of a risk to create a large game. Which is why developers target simple casual games, and tries to nickel and dime with some targeted psychological tricks.

I enjoy more complex game, even with mobile platforms such as Nintendo 3DS. My most played games are Fire Emblem Awakening, Etrian Odyssey IV, Devil Survior Overclocked and Monster Hunter 3 U. The first three games would not even require tactile controls; but I don't think any mobile gamer in the current culture would buy them for 30 to 40 dollars.

With dedicated game consoles the culture of actually paying for a good large game is still alive and well. And I think that is the reason why developers make games for them. If the day comes when free-to-play casual games are the only mobile games available, it will be a sad day for me.

Have you tried merging those scenes? Even if the format is structured and in plain text, it does not mean that a human can manipulate it as a patch. The format is so convoluted and full of magic numbers, it would require a lot of experience to really merge them; or support from Unity itself, and then the choice of serialization is not really that important.

You can manage team work somehow with prefabs. But I would like to see something like Havok Vision Engine's layering system, where every layer of a scene is it's own file, thus with file locking you can work on a single scene as a team. For example, you could split the scene in layers by developer, and then have someone integrate them in proper layers. Or you could just split specific work between people with lighting layer, static layer, collision layer and so on.

Lua is a really simple language, and is quite malleable to different use cases not included in the language per se. Usually in my book, it is an advantage, for example how many Lisps can implement new features that seem like language features, but aren't.

But this simplicity can have a downside, as there might not be canonical ways of doing things that users are accustomed to. For example, object orientation. It could be a hard sell to someone coming from an object-oriented language, when you have to understand, and choose between multiple different styles of object-orientation and implement them consistently in your project, or use one of the many libraries made just for this. For example, see http://lua-users.org/wiki/ObjectOrientedProgramming

Lua really is simple, but it not always easy.

GPG uses asymmetric keypairs for encryption. You generate (at the same time), two different keys: a private key and a public key. The private key is your identity, which you can use to sign outgoing messages, and decrypt incoming messages. The public key, you share to your associates can be used to verify your signature, or encrypt messages only meant for you.

With asymmetricity, the public key is a key which can only encrypt the message, but even the sender cannot decrypt that same message again with that key. Only the single unshared private key can decrypt them.

This ofcourse means that all parties must have their own key pair, and the public keys have been shared between them. Also they must use a GPG compliant program to encrypt/decrypt or sign and verify the messages.

It will be really interesting to see, if Apple can emulate the Nintendo 3DS experience with a bolt on controller for the iPhone. And if the game developers are willing to compete in a much smaller market of iPhone users who actually have, and are willing to carry the controller with them. And games that, go both ways, won't be able to compete with games designed for D-pad + buttons control.

Older gamer used multple cheap techniques to prolong the otherwise short games. But I do think that many of the modern games are really easy by design, when compared to the old games.

For example the 8-bit and 16-bit era games are skill based, where you have to dodge multiple bullets, have good reactions to enemies and even the environment around you. And you are punished for your mistakes; which sometimes borders on cheap tactics.

Many modern games have reduced to button smashers with little to no need for any other than simple timing skills. Shooters have autoaim, and with normal difficulty levels you are a bullet sponge, even a rocket might not kill you. Of course there are a lot of exceptions, and higher difficulty level in some games can help.

The games can still be really enjoyable regardless of the design change. But the ongoing evolution to more cinematic gameplay is really worrying to me. For example, Ryse: Son of Rome, that was revelaed for XBox One an E3, looks really great visually, but the gameplay seems more or less like Simon Says. You as the player are included in amazing set pieces, by letting you press one button at a time, as soon as the game tells you to; and see how the game character and the world reacts to that.

It's a scary trend to me, that the stories cannot be told by the gameplay anymore, but with cutscenes where you have little or no effect on the result. There is a world of difference letting me as the protagonist struggle and get better, than having a non-player character tell me that in a cutscene.

For those not familiar with Emacs, IntelliJ IDEA with La Clojure is also an okay choice. I use IDEA for Python, Java and Scala; and still switch to Emacs when I code in Clojure. The reason is that Emacs has really strong toolset for LISP, where many of the features are missing from other environments, or implemented partially.

Slime/swank (nrepl replaces it, but I'm just slowly transitioning to it), provides code completion, documentation lookup, REPL, macro expansion and even live code updates on a running application; which can be a bit of a pain to setup on other editors. And the integration in Emacs is really great, as the repl buffer is really just a text buffer, the same as the one you are coding in.

But the biggest reason for me to code LISP in Emacs is paredit. It really makes all the trouble with balancing parenthesis and moving around the sexps really easy. It might seem counter intuitive and a bit troublesome at first, but I really recommend you to try it. For a short and enthusiastic video on paredit, see http://www.youtube.com/watch?v=D6h5dFyyUX0 -- and maybe the other Emacs Rocks! videos to learn more about modern Emacs.

Clojure has excellent support for hot swapping functions and data; which in my experience is far ahead of anything that Java has. The system introduced in this article is for reloading code but with a consistent state.

For example, if your application includes some state from previous actions. Then you change a function that acts on that state, but with a different protocol (e.g. data structure expectations changed in the function). Then your application would not work, as the old state is invalid for the new function. With techniques like explained in the article, you can quickly "reboot" your state to be consistent with your new code by reseeding your system.

I guess the word "lie" is too negative word to be used here. It's as much or less a lie as not including all the different revisions of the code written before the final version.

As you said, sometimes it's a good idea to refactor the history, or not comment on algorithms that was not chosen for the problem at hand. But there are times when that information might have some value.

I have different modes of working, and switch between them depending on the context.

When I wish to learn something new, I choose a new technology stack. I read a lot about it, and try my best to code in an idiomatic and clean style for that tech. I might have a couple of iterations right from the start, where I just want to get something to work, and then change it to be clean.

Then there is the kata-mode, where I do something that is familiar to me, but just try to do it better than before. Just to improve my existing skill set when I don't have the energy to do something new.

Then there is the project mode where I got to get paid. This is where the shortcuts are made. When I have time, I will code a version that works with some planning; and I'm talking at micro level, macro level planning has been done already. Then I commit it. And then I refactor it, if I'm happy, I will amend the previous commit. But when the pressure gets higher and there is just no time, the second step is dropped. This is where the technical debt starts accumulating, but at least it works and the project progresses. The first moment I get more time, I try to do some refactoring, but at this point, there never is time or reason to fix all those TODO's and broken windows.

It's a balancing act for me; and at work I have seen both extremities of this balance. And those who are the most experienced, can switch between different modes depending on the deadline; and I see that as one of the most important skills to have in our craft.

I've heard that the reason for this is the XCode project format. The purpose of AppCode is to be a better IDE for iOS/OSX development. But if the future version targets cross platform development, not meaning cross platform on the host side, but cross platform on the compiler target side; it would probably mean that the project format support should support Makefiles and other build systems; and hopefully that would be integrated in IntelliJ.

I would think that they have statically linked it, which is why I thought about using a debugger to catch the data. With dynamically linked library, such as OpenSSL, it would be quite easy to capture the data.

How about catching the packets before SSL? I have no knowledge about modern Windows debugging, or how Simcity might block a debugger. But I guess you could pinpoint the location of the messages just before SSL encryption, and just dump them out?