Ayende @ Rahien

Oren Eini aka Ayende Rahien CEO of Hibernating Rhinos LTD, which develops RavenDB, a NoSQL Open Source Document Database.

You can reach me by:

oren@ravendb.net

+972 52-548-6969

, @ Q j

Posts: 6,814 | Comments: 49,057

filter by tags archive
time to read 2 min | 315 words

Here is an observation on learning. When I was at high school, I was thought Pascal, and I couldn't for the life of me understand dynamic memory allocation. I had little problem with everything else, but dynamic memory allocation (better known as pointers) was a mystery wrapped in an enigma stashed inside a headache.

About a year later, I was learning C++, and was one of the first in the class that grasped pointers and their usages. I remember trying to explain ***pppHead (sparse matrix) to another student, and he drew blank after the first level of indirection. I don't think that the quality of the teachers was that different,  and the material is basically the same, but I grokked the second and couldn't figure out the first.

I have run into this many times since, usually a piece of technology just doesn't make sense to me, and at one point, it clicks together, and it is "Oh, that is simple!"

For a while now, I have been feeling my lack of knowledge in the area of parsers, and I kept trying to learn ANTLR on my own. I got to the point where I could read EBNF fairly well, and actually make sense of it, but taking the next step to actually building a language has been beyond me. Yesterday I picked up The Definitive ANTLR Reference, and I have been going through it with a fairly rapid pace. I don't think that at my level, the book is offering something that isn't already available online, but I have been able to understand how things mesh together much better now.

I feel that now, I am not competent with parser building, it is certainly something that I can be with a reasonable amount of real world practice. In other words, I think that I am going to be able parsers and parser building to my toolbox.

time to read 3 min | 589 words

Rocky Lhotka paints a grim picture of our industry 20 years from now:

“Developers” employed in corporate settings become general practitioners: people who know a little about a lot, and pretty much nothing about anything. Their role is primarily to take a guess about the issue and refer the customer to a specialist.

As you can probably guess from the title, I don't agree. Rocky makes a good point, but I simply do not agree with his prediction.

I have not a clue about how SQL Server Tabular Data Stream work, nor do I have any interest in it. That doesn't mean that I need to find a SQL guru to do my databases. Or understand what goes on the bus when I am drawing an image using GDI+. The whole point of abstracting away the underlying layers is to let me focus on doing what I want without getting distracted by the implementation details.

I am one of those that like to have a good understanding on what is going on under the hood, mainly because I am also one of those that keep running into problems because of this stuff. Nevertheless, quite a bit of it Just Works. And unlike the medical field, which is what Rocky compare the devs into (at least it is not construction again :-)), we can move into new areas relatively safely.

There is a place for specialists, certainly. If my database is running slow, and I can't figure out why, I'll call up a SQL guru to point out where I am being stupid. But, that is not something that I would need on a general basis. I expect developers to know a lot, about a wide variety of subjects, but I don't expect them to be experts in all those fields. They need to have a good understanding of what they are doing in any field they are going to spend significant amount of time on, and they should definately have at least one or two areas of expertise where they excel.

I expect to see a lot more work going into building non leaky abstractions in the future, and I think that we are getting better and better at it. Furthermore, I believe we will see a lot more emphasis on Not Surprising The Developer. I fully expect being able to get a new framework, read the overall idea and be productive in a matter of a day or two. If I am not, then the fault is with the framework, period. This means good naming convention, discoverability and googlability, among other important attributes.

In short, technology scale better than people, so I expect technology to fill the gaps. The alternative that Rocky suggest doesn't hold water, in my opinion. If I need to hire a whole bunch of consultants at 250$/hour just to get a BuzzwardTechnology working for my forms over data scenario, I'll simply stick with what I have now. BuzzwardTechnology be damned!

Technology doesn't exists for the sake of technology alone, it exists to answer some sort of a business need, and if it can't handle that, it wouldn't succeed. Handling that, by defination, means that I can get my money's value back.

time to read 2 min | 281 words

There is a tendecy for developers to disregard looks for function. I am certainly one of those :-) For a long time, I used to work on UI that were functional, but looked like this:

(Image from clipboard).png

This is functional login and it certainly work in the sense that this is doing what the spec says it should. But compare it to this:

(Image from clipboard).png

There isn't any additional functionality implemented, but there is a host of stuff that are visible that make the work much easier. You can see what you need to do (remember me, email password, create account), and it make it much easier to show the work in progress to customers.

One thing that is not immediately evident, however, is that it feels much better to work on something beautiful that something merely functional. A while ago I implemented a login page that had a whole lot of stuff in the back end that were really cool. But it wasn't until I saw the page (which looked very much like it would look in the end), that I felt a surge of satisfaction.

There is a whole list of reasons that I could give for why working on near finished UI at all times is good, from demoability to ensuring functionability, but the most important reason in my opinion is that it helps to know that you are working on something pretty. And that can give a sense of satisfaction no abstract factory can build for you :-)

time to read 2 min | 323 words

(Image from clipboard).png

I just took 070-315 MCP test. Frankly, I was appalled by the level of questions that they had there. I speak here as both a technical guy and as a teacher. I used to be responsible for teaching and educating, and I am familiar with the concepts of good tests.

If I was handed this test for evaluation, even without the technical knowledge to judge the questions, I would have failed it. And question that has the following as answers is fatally flawed...

A) products.Merge(otherProducts, true);
B) products.Merge(otherProducts, false);

And that is leaving aside my own feeling about my own feeling about the whole DataSet / DataTable issue. Asking about the specifics of API in this manner is simply wrong. Especially when it is a boolean parameter. What are they testing, exactly?

Another question had the following query:

"select * from Users where UserId = " + userId

And the correct answer was something along the lines of:

dr.GetInt32(0);

I have so many issues with both question and answer that I don't know even where to begin. Given that I wouldn't hire anyone who tried to give me this code as an answer to a question, I have a lot of issues with this being a question.

Just a few notes:

  • Concatenating strings to create queries.
  • Not using parameterized queries.
  • Using raw numeric indexers to get the data from the query
  • Relying on the DB orderring of the columns.

I never had that much respect for certifications in the first place, but this is really pushing it. If this is the level of the tests, I am going to start putting job ads that says: "Not certified by Microsoft - BIG Plus."

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. RavenDB 4.2 Features (5):
    21 Mar 2019 - Diffing revisions
  2. Workflow design (4):
    06 Mar 2019 - Making the business people happy
  3. Data modeling with indexes (6):
    22 Feb 2019 - Event sourcing–Part III–time sensitive data
  4. Production postmortem (25):
    18 Feb 2019 - This data corruption bug requires 3 simultaneous race conditions
  5. Making money from Open Source Software (3):
    08 Feb 2019 - How we do it?
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats