<quote><p>I remember Cloudera saying that most people use hadoop for ETL. Not sure if you've checked, but hadoop is like the ne plus ultra of ETL tools. It's worth a look if you have to transform lots and lots of data.</p></quote>

The problem is you still have to Extract data from other systems, Transform them to make them suitable for Hadoop and Load them in HDFS (or S3). Once that data is available to Hadoop, it becomes extremely powerful.

Practically all analytical systems have the same issue. The reason to use an analytics system, like Hadoop, is because the database is not fast enough to query. I say "fast enough" because even though many databases *could* be fast enough, it become contentious to perform queries that utilize resources required in production.

I'm not holding my breath for ETL companies to arrive that make this initial process easier as each client would have different network, databases, and software that would have to be supported. A better tactic is to work towards publishing streams of data from the start and building an ETL system that can help distribute the leg work across an organization.

One thing to consider is when a refusal happens. A family member of mine was given 14 shots totalling well over 30 vaccines at the age of 2. Tragically, she has autism. While it is controversial to conclude that the vaccines caused the condition, I don't believe it is controversial to consider vaccination 14 shots at 2 years old extreme.<br><br>I agree that vaccination is a good thing, at the same time, the schedule of these vaccines should be considerate of the child's development. The same goes for categorizing what vaccinations are required. When I was kid we didn't have a chickenpox vaccine and most people my age ended up getting at some point. Refusing a child at a school because they lack a chickenpox vaccine seems silly in my eyes.

This seems like a magic version of logic programming. Rather than defining precedural instructions, you provide a set of rule that a logic engine then uses when accepting input. My understanding is this is how Prolog and Datalog work, an example being Cascalog in Clojure where you define a query and the logic engine will infer the necessary joins and such to make it happen.

Generally this model of thinking appeals to me, but in practice it is difficult to get right unless your language has explicit support for it. Functional languages with tools like pattern matching and multimethods are a great example of supporting this kind of workflow.

In some ways I can see the model handling extremely complex problems. With that said, the reactive programming model seems like it misses the advantage by simply reacting to changes in input. As others have mentioned, what happens with circular reactions or highly inefficient operations? A logical programming model allows for an engine of sorts that analyzes the "reactions" in order to find where it can be optimized as well as decide whether it is flawed.

Obviously a logical programming model is not a panacea, and I'm not an expert, but it seems a more genuine attempt at handling the sort of complexity that reactive programming aims to solve.

I've found the best way to learn a code base is to start editing it. There are almost always formatting details and names that don't feel right. Start changing those and see what happens. The process will force you to understand the logic and help you really understand the code. Even if you throw all your formatting changes away, you'll definitely learn something.

Hopefully, the project has tests as well that will let you see if your formatting changes break things, in which case you've begun to understand the relationship between different code blocks.

I've traveled 150+ dates a year while keeping a full time job and I can say that it is not easy. While most of that time is spent in a van and in nasty green rooms, there have been some helpful tricks that have helped a great deal being productive while on the road.

  1. Keep whomever you work for in the loop. There are going to be times where you are missing a meeting or will have trouble being available. Most of the time isn't a big deal if you're up front an open about where you are. It also helps if you end up keeping somewhat "off hours", which I typically do.
  2. Get a MiFi or some other reliable internet source. Coffee shops and hotels often have flaky connections. When you do need to have that meeting or restart some services, it is beneficial to have a connection that is reasonably reliable. Also, if you use Linux full time, a MiFi is like any other wifi, which can mean less futzing with USB drivers.
  3. If you work while "moving" (ie in a van, train, plain, etc.) then make sure you don't get motion sickness. I used to take Dramamine and Bonine, but both made me extremely tired and put me in a horrible mood. Since then I keep a lot of ginger chews / gum and natural motion sickness remedies. Specifically, I use a chewable tablets with Nux Vomica and Cocculus Indicus. You can pop that stuff like candy and it really works.
  4. Have different themes available for your text editor. When traveling, having a light and dark theme is helpful when you may not have the best natural lighting or you have to battle some sunshine outdoors or by a window.
  5. Battery life is critical! A small power efficient laptop is really helpful, especially if you have to carry it around. I also keep a small power inverter for working in the car. You want to get the lowest power possible as they are less likely overheat and break.

I've also found that using a email client that can work offline is helpful at times. I use Emacs + Mu4e with offlineimap and have found it to be helpful at times. Org-mode in Emacs is also helpful as it provides me with a timesheet and a helpful system of organizing my notes that is close to the code. This is nice b/c when traveling, you typically will have shorter time spans to focus. Being able to clock out and keep a note of what you were working open when you close your laptop can go a long way when trying to get back to work.

Good luck!

One caveat I'd argue is to recognize the difference between the ability to program vs. programming in PHP. I had a terrible interview where the person chided me for not knowing a specific array function. While I'm sure he was correct that the array function was a better tool, I also got the impression he was not evaluating my skill as a programmer, but rather my knowledge of PHP.

When I would interview people I would often ask about more general web development aspects. For example, what happens to the request before you get your $_POST (or whatever language specific object)? It was always surprising to find that many people had no clue what really happened and would respond that it was irrelevant since the web framework or language takes care of everything. This is not a good answer since it doesn't reveal any understanding of HTTP as a protocol as well as reveals a lack of interest to dig deeper.

If I were to ask a developer to write a web application on the spot, I wouldn't really care about the language as much as I would ask about what the different parts of their framework/tool/library did in terms of responding to requests.