jrmenon · HackerTrans

vor 11 Jahrendiscuss

Fully agree with you here. Wanted to also add that even the 'parsing' of text is easy by using standard tools like awk, sed etc.. rather than writing custom code to debug binary protocols. In addition with protocols like JSON, it is easily extensible without worrying about where new data fields are added as long as backward compatibility is maintained - i.e. if designed correctly, the server can be upgraded to accept new fields while still working with older clients.

jrmenon

vor 11 Jahrendiscuss

Disclaimer: I come from C++ and PHP world, but in the last few years, have been working in Java after a long gap.

So here are the pros and cons of Java I see (not comprehensive but somethings that I tend to care about):

Pros:

1) The strongly typed features does help in finding potential bugs during compile time.

2) The Generics and Container frameworks seems fairly sane when compared to the complexity of C++ templates.

3) Concurrency features are nicely standardized now - Executor framework, concurrent container frameworks and so on.

4) In short, 'stock java' (without all the heavy-weight frameworks) seem nice comfortable and sane to work with.

Cons:

1) Fairly large and legacy XML-driven frameworks like Spring and Hibernate is a huge time-sink to figure out all their intricacies, not to mention very hard to debug things esp. when some 'business logic' resides in these mysterious XML incantations.

2) While not really a Java problem, but due to these humongous frameworks, there is a tendency to build giant war files with code and configs all bundled together. Need to make a config change? Check it in some xml file, and then build to deploy wars/jars. It takes some work to separate code from configs, and convincing traditional Java engineers to move away from this model - i.e. check configs separately, deploy them independently, restart servers etc.. without any need to build and deploy process.

3) Legacy app-server based architectures where there is apache in the front with IPC overheads to a Java app-server.

The way I get around some of the cons is to convince the engineers to sparingly use the frameworks (just enough to get some basic routing rules to map urls to controller entry points in the MVC setups), use more lightweight servers like Jetty (directly listening on socket ports), esp. when it is just handling some API requests, and sticking with JSON as the payload format.

It is been a challenge but I have had success in using Java in very limited ways, and decoupling it from serving web (jsp) pages and so on.

jrmenon

vor 11 Jahrendiscuss

Actually the abundance of water was detected in some young sun-like stars:

http://www.popsci.com/technology/article/2011-06/herschel-sp...

jrmenon

vor 12 Jahrendiscuss

Some of the best programmers I have seen have a non-CS background, and were self-taught.

Based on how I interview (and also on various interviews I have attended), here are some suggestions on how to begin:

1) Start with some basic data-structures: a) Arrays b) Linked List: both single and double c) Hash Tables d) Binary Trees with some familiarity to one or two types of balanced trees - e.g. Red-Black and/or B-trees. e) Stacks and Queues - built on arrays and/or linked-lists

If you can practice it with writing some code in C or Java, that would be a big plus. You can get a hang of the aforesaid structures by coding the usual functions - find an element, insert, modify, delete, iterating through all the elements etc...

As you are doing it, get a feel of the big-O notation - i.e. understand the various tradeoffs on why you would pick a certain data structure to solve a particular problem

2) Get some exposure to search and sorting algorithms and understand the various trade-offs - maybe start with linear and binary search, insertion sort, merge sort and quicksort (for the latter two, you will get an idea of divide-and-conquer strategies, recursions and so forth).

Most advanced data-structures/algorithms are built on the aforesaid foundations, so with (1) and (2) alone you have strengthened it, and based on your interest, you can dig down further if needed to related areas - e.g. graphs, linear algebra problems etc...

3) Get an exposure to OS/System level programming if possible - e.g. if you choose Linux, you can get some idea of processes vs threads, schedulers, memory mgmt, file and network IO etc.. At the very least, writing some toy code here, say opening files, forking a process, socket IO and so forth will give you some practical exposure.

4) HTTP/Web services: You already mentioned meteor.js so it looks like you are already familiar here esp. with tools like Firebug to see raw HTTP payloads and so forth.

5) Databases - SQL, and maybe some NoSQL use-cases.

6) OOP and Design Patterns

As you get a grip on the aforesaid areas, the more code you read, it will add to the practical use-cases. For some of the topics, you could get familiar with the area using any of your favorite scripting languages (including posix functions for point 3).

Give yourself ~ 6+ months and get as much exposure with practical use-cases.

jrmenon

vor 12 Jahrendiscuss

> Software engineering in life-critical applications is serious business.

Probably one of the most tragic cases of a SW bug:

http://en.wikipedia.org/wiki/Therac-25

jrmenon

vor 12 Jahrendiscuss

Was wondering if the headline was misleading in mentioning 'uranium free'...

Incidentally India's 3-stage plan is meant to use its vast Thorium deposits in the 3rd stage:

http://en.wikipedia.org/wiki/India%27s_three-stage_nuclear_p...

which eventually uses Pu-239 from the fast-breeder reactors (2nd stage) as the neutron source to take it to the 3rd stage.

IIRC, the original plan predicted to reach the 3rd stage in the 90s', but due to various sanctions, it is still stuck in the first stage; probably it will speed up now due to the Indo-US nuclear deal during the 2nd term of the Bush administration.

jrmenon

vor 12 Jahrendiscuss

Big fan of kqueue() mentioned in the article. IIRC with sockets, it not only tells you if the socket fd is ready (say for non-blocking read), but even informs the number of bytes available to read which allows you write efficient code (i.e. not to some fixed buffer where you may need to loop in again to see if more data needs to be read).

Also I think for files/directories, you can listen for any changes that occur.

Wish this was officially available in Linux.

jrmenon

vor 12 Jahrendiscuss

Thanks for the pointer here. Will explore it more closely.

jrmenon

vor 12 Jahrendiscuss

How does this compare with Kohana?

http://kohanaframework.org/index

Note: I tend to use frameworks largely to enforce safe db queries. IIRC, Kohana does all the needed escaping transparently. Might seem like an overkill but it is better than relying on the discipline of individual developers.

jrmenon

vor 12 Jahrendiscuss

Nothing unusual about the lock-in strategy. I would argue Apple does the same with iTunes/App Store walled-garden, same for Facebook, and Google - their Android playstore, GMail/GDocs esp. for small business.

It is been a dream for many companies to own the full stack - client onwards all the way till the server. MS tried with Active-X controls in their browsers which only worked well with IIS servers. Apple is pretty much doing the same with their offerings.

Full-spectrum dominance.

jrmenon

vor 12 Jahrendiscuss

Interesting debate.....when I see the comments here, I am reminded of this most-probably a misunderstood book by Francis Fukuyama:

http://en.wikipedia.org/wiki/The_End_of_History_and_the_Last...

It is a must-read esp. if you are inclined towards cultural determinism. IMO, he seems to persuasively argue against all that, and provide good counter-points on how people can change over time.

jrmenon

vor 12 Jahrendiscuss

More on braces, I am squarely in the Allman camp for the reasons described here:

http://www.experimentgarden.com/2009/07/facts-behind-code-in...

It is amazing the old-style K&R still persists. I think there was one more reason it was preferred in the early days which is not mentioned in the aforesaid link: storage space which was also expensive. The K&R style saves a new-line char which would be a significant saving in large codebases.

jrmenon

vor 12 Jahrendiscuss

Conversion tracking is definitely the norm in the app-install world.

However what the OP did is sort of life-time-value (LTV) analysis which in the long run might give a better indicator on return-on-ad-spend. Post-install tracking is available now via various 3rd party tracking solutions.

It does involve more up-front work on an app developer - i.e. find all the important metrics in the app that is relevant (sign-ups, various activities like virtual good purchases etc...), and track these metrics over time.

There are quite a few flaws in the OP which most of the comments here have captured, and provided remedies to fix them, so I won't repeat them here. I look forward to the follow up here.

Disclaimer: an ex-Admob engineer + currently working in a mobile ad startup.

jrmenon

vor 13 Jahrendiscuss

FWIW, our start-up began on AWS during early days, but finally due to cost constraints, migrated most of our servers to our own h/w setup. We had substantial number of servers of varying types on AWS (live servers, full hadoop cluseters etc..), on east and west regions, lots of EBS storage etc.., so not some trivial setup.

We really liked AWS, and the support we got for most of the times was good, but as we had 24x7 live traffic, even with reserved instances, the cost finally caught up to justify the move to our own hosting solution.

One thing that the made the migration easier for us was that from day 1, we decided to treat AWS as a co-location, hence we set things up with the usual open-source s/w stack (i.e. avoided proprietary Amazon solutions like dynamo, messaging solutions etc.. maybe just used S3 for offline archiving of logs. It was tempting to build on their components, but ended up building it ourselves.), including own own hadoop setup. When the time came, we could easily migrate things out.

Hope this gives some perspective. Still a fan of AWS, and if I were do another start-up, would follow the same script all over again.

jrmenon

vor 13 Jahrendiscuss

From the article:

"The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture"

Couldn't agree more... I have been doing OOP for a while in various prog. languages, and I had come to similar conclusions...It doesn't really help you focus on core ways to solve problems: focusing on algorithms.

Another read I would recommend is from the author of C++/STL:

http://www.stlport.org/resources/StepanovUSA.html

See the answer to the question:

"I think STL and Generic Programming mark a definite departure from the common C++ programming style, which I find is almost completely derived from SmallTalk. Do you agree? "

Note: not trying to endorse C++ templates here either...have my own gripes here but it did bring the attention back on algorithms and data structures.

jrmenon

vor 13 Jahrendiscuss

JPL seems to have had quite a few founders. I recall reading about Jack Parsons who was also into occult matters:

http://en.wikipedia.org/wiki/John_Whiteside_Parsons

Happen to run into his story while reading about the history of Rocketry. His story even takes a more bizarre turn with L Ron. Hubbard, and finally his death in a mysterious explosion.

jrmenon

vor 13 Jahrendiscuss

Not just the Nordic model, but even the achievements of some European countries (notably Germany) and Japan, would have been possible without US security guarantees?

Essentially the US/Nato is the main protector of Western interests, and American taxpayers ( + deficit financing ) essentially props up these 'regimes' - granted they are more democratic, and there is a great deal of autonomy than a traditional vassal states arrangements.

jrmenon

vor 13 Jahrendiscuss

I have done a lot of scripts/tools to mostly automate or simplify it for non-techs to take over, but probably the one that I am most proud of was a 'mailbox reaper' task that was fully automated by crawling the filesystem in a Netapp storage engine (NAS).

A prior version was a simple python script that ran as a cronjob but it needed lot of hand-holding as it would run at times when the filer was too heavy, and it was annoying to babysit it all the time esp. at odd hours.

The new version used snmp data from the filer to 'gauge' how idle or busy it was (as a feedback loop), and it would self-throttle or 'accelerate' itself in various stages as necessary. Saved the company a lot of grief in storage costs, and it ran like a charm with with hardly human intervention. It kept various stats and logs which could be queried as needed. Also saved a lot of time for other engineers/ops on-call team to focus on other areas.

Looking back at it, it used some crude mathematical models to gauge the busyness of the filer, but this portion was designed to be plugable and independent of how the filesystem was being crawled.

This simple program (set up as a forever loop daemon) got me thinking on autonomous agents and 'self-healing' software in general but never had time to pursue it in a more academic setting.

jrmenon

vor 13 Jahrendiscuss

Not sure if it explains everything though. The comparison may not be fair, but the tax rates in US ~ the 50s and 60s were fairly high too, and yet it led to post-WW2 boom:

Dwight D. Eisenhower

Marginal Tax Rate on Regular Income over $400,000: 92% - 91%

Maximum Tax Rate on Long-Term Capital Gains: 25%

Source: http://news.yahoo.com/eisenhower-obama-wealthiest-americans-...

jrmenon

vor 13 Jahrendiscuss

While not directly related to h/w, one of my favorite reads has been "Unix Haters Handbook":

http://web.mit.edu/~simsong/www/ugh.pdf

Note I am a Unix//Linux fan myself, but it was really eye-opening to read that doc. (it also confirmed some of my early suspicions on what I perceived to be various design flaws).

Also the book was released in the early 90s', and since then, some of the issues discussed in it has been fixed in later releases of *BSDs' and Linux.

It is still an enjoyable read :)