The this reference in Javascript is probably one of the most confusing scoping concepts for people coming new to the language. Understanding, the this reference lets you unlock the mysteries of Object Oriented Javascript and gain a better/more intuitive understanding of how the object model is structured…
As you start using Redis more, you soon find yourself delving into redis' transactions. A traditional RDBMS' view of CAS (compare-and-set) transactions is:
Why does software in the industry suck so much? Having worked at couple of startups and big companies as well, I can quite honestly say that of all the projects/repos that I had worked on, there was but one that didn’t suck. The one that didn’t suck, was I’m sure in no small part due to the fact that it was written by just one person, the CTO of the company, and since it was a license-based SDK, there was a vested interest in keeping things organized. Open source software projects, when compared with industry projects, are way easier to understand and in much better shape…
Javascript has garbage collection, so there’s no way we can leak memory right? Wrong. Memory leaks are pretty easy to create in Javascript much like in any other language that has garbage collection. The problem isn’t that bad when running Javascript on the client – unless you are having a blatantly obvious memory leak that kills your browser everytime the page loads. Writing Javascript on the server on the other hand, means you really have to focus on making sure you are not leaking any memory since your server process is going to be pretty long running…
I’ve been playing around recently with NodeJS and have found the sheer performance to be insane. Apparently it isn’t just me and a lot of other places have been able to significantly reduce their bloated infrastructures down by a lot by making the switch…
Silicon Valley and the rest of the tech industry is going through a very well documented crisis and no, I’m not referring to another tech bubble (although it may be happening). What I’m instead talking about is a chronic shortage of engineers and designers…
I’ve been looking at using Ruby for building up a stateless game server in a MMO setting. Ruby to many people, means Rails, which in turn means, a web app. The typical web app request when viewed through the lens of memory (allocation & deallocation) and IO (DB writes & reads) looks as follows:
Threads are back in style these days. If you were like me, a Java engineer getting into Ruby couple years back, you probably would have seen your fair share of JVM bashing by a few people who relished beating on all things Java, while peddling their half-assed gems as software masterpieces. This is not to say that Java, especially it’s community, loves to over-engineer the crap out of everything they can lay their hands on, but (and this is a pretty big BUT) the JVM is a seminal piece of software. Okay, if you are still hanging around after this rant, I thank you for affording me this indulgence…
For someone coming to test driven development for the first time & even for those who have been dogmatically following it through the course of their work, the question “What do I test?”, still remains. In this blog, I am going to take a shot at answering that question using tools that Philosophy provides, specifically those employed by Immanuel Kant in his ground-breaking First Critique of Pure Reason. Those coming from a philosophical background, can see me drawing a hugely controversial line in the sand, and choosing to remain on the side against the empiricists by my previous statement. Over the course of this blog, I will go on to defend this position and expand on why an empirical approach to Test Driven development is flawed…
Most people thinking of Redis, think of it is an in-memory datastore. This is totally true. However, there is a lot of misconception with the “in memory” part; as being if my redis server crashes I lose all of my data. This part is most definitely not true. Redis persists your data to disk and provides you with all of the knobs you are going to need to need to fine tune how often you’d like this persist to take place, while still eeking out the performance you’d like to get out of redis…
In this post I am going to go through the process of constructing a workflow using payments as an example. As you work more with Redis you soon start finding yourself building out workflow’s, i.e. small pieces of code that talk to each other via Redis. For someone familiar with a Service Oriented approach to building systems this should feel like deja-vu. Except, instead of using a protocol (HTTP, TCP, UDP, AMQP, ZeroMQ) we are going back to CS101 using a good old queue datastructure…