Needless to say, I am really excited, but it does put my current team in quite a predicament, because they really need a developer!
So let’s talk about the elephant in the room, shall we?
The reasoning behind why I am taking a new job is multifaceted, but essentially it boils down to it feeling like it was time to look at what else was out there. There is a lot of interesting stuff going on here, and a ton of benefits, but nothing I was truly passionate about anymore.
About those benefits
The benefits here are great. 5+ weeks of PTO, great insurance, 401k matching, the list goes on and on. And that’s just the standard benefits. Let’s look at a few of the technical benefits:
You get to pick your own platform for new projects — as the only developer, you decide how to solve the problems handed to you.
You get to work with an awesome team — everyone here “gets it.” The people you will work with here are skillful and creative, and understand how the art/science mesh of things work.
You get to solve actual pain points for actual people — most of your users are in the office, or next door. Real people that you can see as much (or usually as little) as you like. Building software that you can see the impact of directly is very cool.
The down sides
As with everything, there’s some “less awesome” pieces of the job as well.
It’s on-site in Lansing, Michigan. No remotesies.
You will be the only full time developer on staff. While that gives you a lot of freedom, if you can’t actually swim, you will want to stay out of this water. There is nobody else to blame when your project isn’t done on time.
There are on very rare occasions (2-3 times per year, we will say) some very tight deadlines. New websites going up in a matter of days. Usually the scope on these is kept fairly tight however.
The skill set required
Realistically, you need to be able to handle everything involved with building a website beyond the html/css. You will have to set up vhosts in Apache, and understand the basic workings of source control (we’re set up with git and bitbucket). Deployment strategies are varied — new stuff uses capifony and capistrano while older stuff deploys via FTP or (and I’m very very sorry) issuing a git pull on the live directory structure.
Current projects you will maintain will involve Symfony 1.4 (current CMS), Symfony 2 (some internal tools), and Silex (other external sites). Future projects can use… whatever you care to use, provided you’re not intentionally leaving a pile of junk for the next person to pick up.
You will be given all the rope you need to hang yourself many times over, so you have to really be self-reliant on completing your projects, as there is nobody else here who can do your job, for better or worse.
Now, this is great for all of us Symfony developers, but it’s also a good thing for php developers in general.
If you’re a Symfony developer already, you know what you’re interested in there, so I’m going to focus on what non-symfony developers can get out of this treasure trove. Also, these videos are also available in French through the talks section.
Using MongoDB responsibly — Jeremy Mikola gives a talk about Mongo DB. Really, who’s surprised? I haven’t seen it, but it’s on my list, and I’m sure, knowing Jeremy, that it is “web scale.”
Dependency Management with Composer — If this is anything like his talk in San Francisco (and I’ll just go ahead and blindly assume so!), Jordi Boggiano gives an excellent overview of what you can do with Composer and how to take advantage of it right away.
Richard Miller gave a talk on what you get from a full stack framework. I haven’t watch this, as I have already drank that particular kool-aid, but if you haven’t made the leap yet, I’m sure he presents some compelling arguments. If, after it, you’re still not sold on full stack frameworks, just wait until Dustin Whittle’s Silex talk from San Francisco is up. It will blow. Your. Mind.
At Symfony Live San Francisco 2012, I gave a little talk. No, really. A little talk. Seven minutes. I’m not even sure I used all of it. That’s not a lot of time, but I think I managed to at least provoke some thinking. At least I hope I did.
Hmm. How do you act like you care about your work, as a developer?
Update: Gregorie Pineau pointed out to me that this was already done, so I will refer you to the more canonical resources: Silex Skeleton and Silex Kitchen Edition.
Update #2: However it does seem that my setup may be even more minimal than even Fabian’s Skeleton, which could be a benefit to some.
One of the inherent problems of micro frameworks is the tendency to just go … willy nilly … and put your files in any ol’ spot. It makes the code look awful and hurts your brain trying to comprehend where to handle your changes, and then your project turns against you.
To that end, I want to help! Who’s surprised? Awww, c’mon! Pretend? Ok. Thanks.
I have created a Sample Silex Install on GitHub that shows some of the best practices for working w/ composer, and getting off to a great start with your next Silex project.
Let’s get this out there up front, writing and maintaining CMSs is my bread and butter. I maintain a large one for my day job, and use a small one for client sites after-hours. I think about them a lot. I try to think of how to make the ones I build better, and most importantly to me, how to improve the user experience.
Let me also point out that my writing style can be a little rambling, but I promise I will get to the point eventually.
Look at the dashboard. Seriously, go look at it now if you haven’t yet. What is all of that, and how could I ever get a client to understand any of it? There’s no way my clients would accept anything like this. And that’s where my brain got stuck. That’s where I started to doubt Lukas’s sanity.
And I stayed that way for quite a while. Maybe a month, maybe two, maybe more. I’m not entirely sure.
Then one night, some of us in #symfony (IRC on freenode, participants were Edler, cordoval, and nveid, as I recall) were doing a show-and-tell of our various CMS platforms. Some were CMF backed, some were not. Somewhere in the mix, it all started to make sense, but we have to look at this one piece at a time.
This goes beyond an API and interface for managing content
At the very core of the CMF project, it is about storage, or rather, using the appropriate form of storage. It’s about using the right tool for the job. It’s about no longer using your shoe to hammer in a nail.
We all put our content in a database, and those databases all offer a various set of low-level tools to help us insert, update, and delete content. As I have been able to understand, the CMF project is about bringing content management to a new ‘minimum standard’. Symfony in general tries to bring best practices from all walks of life into the PHP developer’s toolkit. CMF is doing that for content systems. Those crazy Java guys? They already solved this whole content storage issue.
From the linked Wikipedia article:
A JCR is a type of object database tailored to storing, searching, and retrieving hierarchical data. The JCR API grew out of the needs of content management systems, which require storing documents and other binary objects with associated metadata; however, the API is applicable to many additional types of application. In addition to object storage, the JCR provides: APIs for versioning of data; transactions; observation of changes in data; and import or export of data to XML in a standard way.
HOLY CRAP!
Look at all of that stuff that a JCR based content repository gives us out of the box? No wonder Lukas is pushing this. It’s right in line with the Symfony mentality of giving us a better base line situation. Re-read that quote again. Searching. Storing/retrieving hierarchal data (think folders, directories, paths, children, leafs, whatever term suits you), versions, data migration.
So we have a new way to store our data. What are the downsides? Well, currently I think the only full implementation of a JCR is Apache Jackrabbit. The CMF team is working on Jackalope (which is working, but still missing several JCR features), and there is also Midgard2 (which I am unsure of it’s current level of support for the JCR spec), among others.
About that demo
What finally clicked, I think, is that the CMF demo isn’t to show us what our client’s delivered site would look or work like. The CMF demo is to show us the tip of the iceberg of what is possible with the new framework. It’s part tech demo and part inspection tool. That’s why there’s all of that confusing stuff there. It’s 50 ways of looking at the same data set. The repository. The content repository. Because the content repository is new, and we will want to poke around at it, and see what happens when we do various things to it. It’s the proving ground, not the polish.
