In these circumstances, we have two choices. The first is to accept that our original judgements might have been at fault. We question whether it was quite such a good idea to put our faith in a cult leader whose prophecies didn’t even materialize. We pause to reflect whether the Iraq war was quite such a good idea given that Saddam didn’t pose a threat we imagined.
The difficulty with this option is simple: it’s threatening. It requires us to accept that we are not as smart as we like to think. It forces us to acknowledge that we can sometimes be wrong, even on issues on which we have staked a great deal.
So here’s the second option: denial. We reframe the evidence. We filter it, we spin it, or ignore it altogether. That way, we can carry on with the comforting assumption that we were right all along. We are bang on the money! We didn’t get duped! What evidence that we messed up?
Ok. So this book is a sequel to the The Mahabharata Secret. But belonging to a different series. ( of three books ? ) And yeah it’s better.
The first few chapters of the book are really captivating. Gradually, though, the reader will be able to relate to the author’s style of writing from his previous book. A little over the top, filmy, very similar to Dan Brown, only less thrilling. The plot jumps are a little jerky. It’s starts resembling a Hollywood action movie of the 2000s era. ( Helicopters , explosions, secret medical facilities ) New, yet a little deja vu. It also sometimes feels like the book had undergone a lot of editing. Some of the events have been fast forwarded, while some of them have been painstakingly described in detail. ( the retrovirus infecting the bacteria process ) But still this one was much better than the previous book. I actually enjoyed it, considering that it was this author’s second novel.
Full marks for the history references. The way Alexander’s journey to India and back has been reimagined and linked to the Mahabharata tales, is really impressive. Since, it involves Indian myths and legends, I personally enjoyed reading it and was able to relate to it much more than say ‘The Lost Symbol’ with American Stone Masonry as it’s plot base.
My Rating : 2.5 out of 5
For : History references and reimagined explanations ( samudramanthan )
Against : Weird editing. No emotional connect. Jerky plots.
So we all know one of the tenets of the 12 factor app is to store config in the environment. CodeIgniter allows production and development config and database files to be stored in separate directories. But they all reside inside the git repo and therefore not really safe for storing sensitive values like database connections params or auth codes.
In comes phpdotenv, a really clean way to achieve this. Laravel already implements this and it’s fairly easy to do the same in CodeIgniter as well. Here’s how :
You can skip this step, if you already have Composer integrated to CI.
Composer makes PHP awesome. Although you can implement the above without composer but this method is way more elegant. The following config flag has to be turned on in your application/config/config.php file :
$config['composer_autoload'] = true;
Next create a composer.json file inside the application folder with the following contents :
After that you need to run “composer install” in that directory. If you don’t have composer installed, here is how to do it.
Now we create a pre_system hook to load phpdotenv. This is the most appropriate hook as it is called right after loading composer and before the controller. Here is what my application/config/hooks.php looks like :
And then enable hooks in application/config/config.php as it does not come enabled by default:
$config['composer_autoload'] = true;
A dirty way to do it would have been calling the same code in index.php file. But changing the core files of a framework is almost always a bad idea and makes upgrading/debugging very difficult.
Create a .env file
The hook code was configured to load the .env file from inside the applications folder. You can change that if you want.
And that’s it, you can keep separate .env on your production servers and on your dev server. The values can be accessed via either getenv() or $_ENV superglobal variables.
Nice. So that does it. Let me know if you have something to say in the comments.
To develop as a Product guy or to develop as a Tech guy??!
There are major differences in the approach.
A product guy will focus less on the backend technologies used, accepting a barely working prototype with acceptable design and focussing more on shipping the product out to beta testers so that things that matter can be prioritized. Look and feel will be important. Evolving usability and virality factors will be the prime focus while technology will take a back seat.
A tech guy will look to try out platform candidates before finalizing one on the basis of performance. He will try to incorporate state-of-the-art tools to make the technology stack look impressive. A few learnings on the way will be welcome and will be given dedicated bandwidth. Some delay to launch will be fine.
Is this the reason why product guys and tech guys almost always end up debating? May be.
So in the latest change-set, I’ve upgraded our framework CodeIgniter to 3.0.4. Wasn’t hard since the custom code footprint was relatively small and nothing was changed in the core files.
Next I want to complete the multiplayer part as soon as possible. Before that some challenges, that I can see are:
- How would someone keep track of all the rooms that he has been in
- What happens when a user exits a room. Do we save the room data? If yes, then how is that accessible.
- Need a proper sanity process of the real time feature so that nothing is breaking.
Also in my list are some infra changes
- Doing JS and CSS versioning during deployment.
- Keeping environment related config items separate from the common config items.
There are some feature addons as well :
- A performance card at the end of every run.
- An option to mark a track as difficult or easy.
- The progress meter to be based on characters instead of words.
- Better UI
- Applying continuous sync with server to prevent hacking of score.
- Setting a max value for speed, just to make sure data does not get corrupt.
This is the first post of many to come in the TypeRush Series. In here, I’ll be writing on my learnings and logs of developing typerush.com as a product.
I’ll be trying to use the three step production development cycle : build, measure, learn. I’ll try to focus on things that matter instead of building a “complete” product. I’ll need help in getting feedback and am not sure at this stage how I am gonna do that.
What prompted the development of this product?
I think seeing someone keying into the computer at high speeds leaves me impressed. I wanted to be like them; to be able to type superfast. When a friend introduced me to typeracer.com during college, I was pretty much addicted. I wanted to create a better version of the same.
Who is the target audience?
At this point, typing enthusiasts is what I’ll say. Ideally, everyone who has working on a computer as part of their daily job routine. And kids and teenagers who have a gaming instinct and like to measure themselves against others.
What problem are you trying to solve?
At present it’s just a game. In the next phase, I want it to help people type better and faster.
If you want to take a pilot run at the current product, hop on to http://www.typerush.com
The framework I am working on right now is like a framework inside a framework which has a framework inside it, which turns out to be made up of other frameworks. I just can’t think of going deeper, afraid that i might never come out.