Linq to Entities, not wrong or right

At this point in my career, I have had the pleasure of having Linq to Entities be made both mandatory and forbidden by management decree. All I can say is, whether you want to ban L2E or mandate it, you are wrong.

If you have a simply structured application Linq to Entities can save you an absurd amount of time that can be used to do things like make your application more usable. For applications whose databases can be described by simple one to many, or many to many relationships, Linq to Entities can be quick to code against, have reasonable performance, and present a shallow learning curve. For more complex reporting pages, Linq to Entities can easily leverage stored procedures to increase performance. Yes, there are risks such as an ignorant programmer unintentionally doing multiple full table scans; however, it is unlikely that a programmer who can not be trusted with L2E could be also be trusted to remember to use the count(*) aggregation in SQL.

However, if your database schema is not so simple, you might run into issues with Linq to Entities. If your database has self referencing tables, is denormalized, very complex, or just generally misshapen from consultant raiders, L2E may not be worth the hassle. There is nothing wrong with straight up SQL, it has always worked, and it still does. In the hands of an experienced developer, by-passing Linq to Entities in favor regular SQL and Ado.net can give you access to some very powerful optimizations without sacrificing a robust code base. Although, stored procedures can also be used with L2E to increase performance, this sometimes adds business logic into the database.

In software architecture and patterns, there is no always best solution. Patterns need to be applied on an as needed basis by someone who actually understands the benefits and drawbacks of a given pattern. Linq to Entities is the same way; it has many benefits and drawbacks and therefore needs to be used as needed.

Software Engineer Job Titles (as I see them)

Everyone knows titles are not a big deal, at least when you are a measly software developer. However, the following is what I personally expect from different levels of developers, engineers, programmers, or what ever you call coders at your place of employ:

Intern/Entry (0) - Is analytically minded, but is still struggling with the basics of syntax, ect.

Junior Developer (1) - Has mostly mastered language syntax and constructs, but still needs a lot of guidance to effectively leverage his tools to create a usable piece of software that can be reasonably maintained.

[Mid] Developer (2) - Can work on assigned tasks with minimal guidance only occasionally needing to seek help. May still struggle with translating high level requirements into code. He can be unable to see patterns in a high level in the application, or see them when they are not there. May not be able to deal with ambiguity.

Senior Developer (3) - Able to develop and deploy most applications from to start to finish with no guidance. She has the ability to translate requirements and user feedback into actionable plans. Must also possess the ability to help delegate work. Can deal with ambiguity and make plans to work around it. May have some trouble distinguishing between different design patterns and applying them appropriately.

Okay, some pedants may say the next one clashes with a senior developer, may not be generally used, or claim that software architecture is it's own distinguishable field; but if I don't list it a mid-level developer will not be in the middle of the list!

Architect (4) - Has mastered his area of technology and can immediately spot the causes of obscure errors. Is an expert at translating requirements in to software, and can often understand user feedback even if the verbal feedback contradicts their true intentions or goals. Can head off issues before they become problems. Has very good working knowledge of design patterns and when to they are appropriate. Able to understand how to make larges gains in application performance. Experience is broad enough to know if a language/framework is not appropriate for the problem at hand and seek the necessary expertise. Might be able to write a book in their area of expertise.

How to render a select box with Zend Framework forms.

I was using Zend Framework 2 to make a quick form when I needed to render a quick select box for my user to select a month. I never thought I would be writing a blog post about something PHP related or something as simple as creating a dropdown so that a user could select a month; however, I ran into so much trouble doing so I think it is necessary for me to post my solution for posterity.

I was seriously scouring Google for over a hour; find a proposed solution, test, fail, repeat. The Zend documentation was fairly useless as per usual, so I was left searching random blog entries. Every time I came across something that looked promising I'd see something in the comments resembling the bellow remarks:
READER: This codez doesn't work dude!
AUTHOR: It totes does, you just got to download my custom library add-on first!

Anyway, my luck changed when I stumbled across this blog, it was the first one that had a solution that worked out of the box. However, his method for creating the element differed from the one I had used in the rest of my form. In a sane world this would not have mattered, but, in the real world this happened to make the select box look very different from the rest of the elements in my form. This still gave me a good jumping off point for this solution:

$this->addElement('select', 'Month', array(
      'label' => 'Month',
      'required' => true,
      'multiOptions' => $this->getMonths() ));

Just add an option key called 'multiOptions' and assign it an array where the key is the html value and the value is the html displayed text. Happy coding!