I just got back from MADCamp and oh boy was it a treat! This was my first time to MADCamp, but someone told me that it was only in it's second year, which is really impressive if true. I would have guessed that this camp had been going on for several years based on how well it was organized and the number of attendees.
Isn't It MidCamp, You Dumbo?
Not according to the organizers, it isn't. Next year there will be no talk of MidCamp and MADCamp will entirely replace it. Being MAD is a thing now along with being BAD, NYC, SAD, SANDy, and other ones probably. The MAD in MADCamp is a homage to Lewis Carroll's Alice's Adventures in Wonderland novel and specifically the Mad Hatter.
I saw some presenters and camp goers embracing the MADness already this year, and it will be fun to see more of that theme next year. You can see a lot of session title names to get a picture of what people tried, and one presenter even worked in a poem. There's plenty you could do with the theme, and you should stay tuned to 2016.midcamp.org for more deets...and to see if they can buy out madcamp.org, which sadly has nothing to do with being MAD :(
Onto the Sessions...
I wanted to give a tl;dr summary for those who couldn't attend the camp. I'm only going to cover sessions that I was in attendance and preface my comments to say that the opinions expressed within are solely my own and not necessarily representative of other audience members or even the presenters themselves. I'll try to give you any read-through-the-lines moments I had, but please don't be a meanie in the comments section if that's not what you saw...it's just like my opinion, man :)
Also, note that I'm trying to give the reader the just of each talk with takeaways to boot, and so I'm taking the most specific and terse approach I can think of for what I'd call intermediate Drupalers. A beginner might need more background than I will provide, and an expert my call my summaries too topical, but I'll always provide resource links for further investigation.
- Rethinking Drupal Configuration
- Rendering HTML with Drupal: Past, Present and Future
- From zero to Silex
- Down the Rabbit Hole of Typed Data
- Speeding up Drupal 8 development using Drupal Console
- Off with Drupal's Head!
- PHP Code Analysis Through Unit Testing
- On PhpSpec and Not-the-Drupal-Way: follow the black kitten through the Looking Glass
- Grunt All the Things!! Even Drupal!
- Remote Control: How to manage your distributed team’s time and get stuff done!
For my config in code itch, I was debating on whether to go to a session on how to better use Features or this session on "Rethinking Drupal Configuration". Since I never really liked using Features myself, I'm always looking for a better feeling alternative. In this talk, the presenter put forth the Config IN Code (CINC) module, which aims to take a different approach to thinking about Drupal and configuration.
The novel part of the module to me was going for a code-first approach. Other modules, like Features, export configuration from a GUI form to code rather than the other way around. One problem with this is that the exports tend to be very verbose. Take a view, for example, that can end up being several pages long just of configuration statements.
The presenter made a very good point when he said, "why should I have to know what a filter on a view looks like to change a filter on a view?" You should really only have to describe the type of filter you want instead of all of the possible values that could come with a filter. There's a reason that default values exist, in essence.
Another really interesting point made was the fact that the UI with configuration usually limits what we as developers think is possible when in fact you can do a lot more in code usually.
Let's say you want to incorporate some sort of functionality that needs configuration input into a module but you don't have the screen ready yet or can't imagine how the user would interact. That doesn't mean you can't build the code that will one day support a nice GUI for users. By not extending your code to handle this configuration idea initially, you can make it really hard to go back later and do it because users will be accustomed to storing their configurations in a certain way.
I do think Drupal configuration needs re-thinking and am hopeful that there's still time, in D7 contrib space even, to approach it from a different angle. Good talk.
One thing that came up later in the camp for me was someone telling me about the Patterns module and how YAML configurations were there in Drupal contrib only to fade away and then now come back for D8. Not related to this talk, but I thought I'd throw it in the config talk I went to since I loved learning this tidbit.
I loved the history component to this talk. If you've ever wondered where Drupal's "div-itusness" came into being, you should do yourself a favor and watch this talk.
I was amazed to learn that front-end devs were once told not to mess with template.php under a mantra called "sustainable theming". The idea was that if you did all the styling in CSS then you could change the presentation layer without changing the theme.
Now that we want semantic markup and "pretty" theme files, front-end devs tend to clash with Drupal's tendency to expose the data layer in CSS classes.
The talk ended with the a look into the future and the idea of a decoupled theme layer separate from the model/data layer where front-end devs won't have to know anything about PHP to work with Drupal. Of course, "headless Drupal" was mentioned with all the mess of where is the neck?
At the end, an interesting conversation emerged on whether Drupal should be truly decoupled in this way. Drupal's history relied on letting the end user use GUI tools to mess with design elements and providing them shiny buttons. This lies in contrast to the consummate front-end dev who wants to use build tools and live entirely in design components and templates as being a source of truth for design.
You say headless, I say headcheese...
Ah, the great crell, Mr. PHP himself. I had heard about Silex before and since it is a micro-framework using Symfony components, if you've worked with D8 or Symfony, you'll feel right at home with Silex.
Larry did a nice demo of starting from scratch and building a Silex app before our eyes...well at least sequentially from Git branches, but that is still impressive in the scary world of live demos. The application was a Twitter clone sort of and the code is available to look at on Github.
I kept marvelling at how Silex's API seemed remarkably similar to Node/Express, and after I left the talk, a quick internet search revealed that others had the same thought. I really love when you notice design patterns across frameworks or languages, because it makes you feel like you're "getting it".
Check out the code base for this talk at least if you've never seen Silex. It'll get you more "off the island" and hopefully you'll use it when the shoe fits. Drupal shouldn't and can't do everything for you.
This was definitely a "frontier talk", if I can make up that category. The presenter told tales of his struggle with the Typed Data API, and this struggle was definitely over my head, at least for now.
If you've used the Typed Data API in D8, I'd check out the talk. If you're wondering why you'd ever want to use the Typed Data API, the answer is that a lot of Drupal systems (think Rules, Panels, Tokens) will use this API, and you'll get exposure to those systems for free if you include Typed Data in your modules.
Also, props for the poem and other Alice in Wonderland references in the talk!
I unfortunately came in late to this talk, but I have used and like the Drupal Console. As Drupal 8 APIs are still changing and documentation is often outdated, the console can provide you with that boilerplate code you won't have to track down.
A new learning feature and web interface to generate module code are promising additions for those trying to learn Drupal 8. No need to make learning D8 harder than it is for some, and hopefully the learning component will take off.
I did want to know the relationship between drush devs and console devs, and as far as I could tell, they talk to each other but the tools don't seem like they will merge into one by D8's release. The console still doesn't have site alias support, and this is something that the drush devs might be able to help the console devs out with.
Interestingly, Laravel and their use of the Symfony Console came up, which was another "off the island" chance for Drupal people to interact with the non-Drupal PHP world.
The discussion of this talk was hard to hear since the room was changed to the larger keynote space. I fortunately could hear well enough to get something out of the discussion, but I know some people didn't like this session just because they couldn't hear the interaction or discussion.
At times, the discussion of "headless Drupal" centered around the question of "should you do it?" The consensus from the panel seemed to be "only if you have to".
I have to concur with that opinion right now. Drupal can't and shouldn't do all the things!! By de-coupling the presentation layer, you lose a lot of accessibility and SEO things that Drupal does out-of-the-box for you and end up fighting against the coupling.
Why not use some other framework to make your headless application? Hell, you'll have to know Symfony soon enough so why not just make a Symfony app? Do it with Rails...get off the island...
The one good part about the headless work being done in Drupal is that it draws out the question of where the neck is in Drupal's case? How loosely coupled should the data layer be from presentation? What do you gain and what do you lose? All valid questions that make for a good debate.
For a person who hasn't incorporated unit testing into his workflow yet, I always like to try and push myself towards it by going to talks like this one.
The code coverage tool used in the presentation was nice and pretty and definitely something I'll set up when I start implementing unit tests myself. It can tell you very quickly where the biggest risk in terms of untested code is in your application's codebase. From that CRAP score, you can logically attack the weakest method and make your code more robust.
The presenter mentioned a CRAP score of 100 or lower for Drupal's codebase as being a good number to try to reach across the board while 30 or under might be something to look for in other PHP projects. PHPUnit is an interesting project to look at in terms of code coverage, and I intend to explore the code coverage tool by looking at that project sometime soon.
In this talk, the presenter's demo fritzed out on her so some of the slides were hard to see, but she was entertaining enough to make up for that gaffe.
Like I confessed above, I have sinned and not done my part in writing tests for my code, so my take on this talk is from a purely "what should I start with?" angle. I had worked with RSpec a little within Ruby code, but xSpec tools are not that familiar to me yet.
The presenter pointed out that there are three types of tests you can write: unit, integration, and system tests. Currently, Drupal has way more system tests than unit tests and no know integration tests. This is one reason why code coverage tools will tell you that the Drupal core codebase is not that well covered...because they only count unit tests.
For me or anyone not doing any of these tests but rather having a QA person click around, you should just start with unit tests before you have a BDD talk at your company. That was my takeaway.
I'll try to use PHPSpec as I go on my unit testing journey as it generates boilerplate for you, but I don't know or remember enough from the talk to say much more.
I've used Grunt and Gulp before so I went to this talk to see if there were Grunt tasks that I didn't know about or tasks I didn't think to automate. I'm not that into dev-ops so I think I didn't get too much out of this talk, but you should defintiley watch it if you are. Good presenter.
One great point made that resonated with me was the fact that you can use grunt to kick of your CI tasks in something like Jenkins without having to know a lot about bash. I always feel stupid in bash but only having to know JS is a great way for your team to not need someone with that expertise.
What I liked most were the resources mentioned. Automating template generation and insertion of PHP into design mocks was an idea I had never thought of. I have been thinking of how to better connect design to development and wasting as little time transitioning designs to usable templates, and the resources mentioned blew me away.
Also props for bringing up the PHP League. I'll use that resource sometime...
- MADCamp link
- Phase2 grunt tasks
- Pattern Lab, static site generator focused on prototyping
- PHP League, packages
I came into this talk with a bad previous experience working for a virtual company. So, I wanted to listen in and see what the presenter had to share about making the remote work experience tolerable and productive and fight her if we disagreed. No joke, I get that worked up about this stuff, because my experience was that bad...plus I left a stable job for it.
Luckily, the presenter had all good pieces of advice for teams who work remotely, in my opinion. If you work remote and your company is trying to get 40 billable hours out of you each week, you should probably look for other work. I heard a limit of 30 hours a week for scheduled time, which is much more reasonable.
Also, there was discussion of how to incorporate professional development when you can't gather your workers together. Obviously, encouraging them all to meet at Drupal camps and cons is a great idea, but there was caution as to whether you should schedule that into your team in a managerial way.
I'm a big fan of explicitly sanctioning things, so I would like to see virtual companies come up with more thought on the 10% time professional development idea. While you want to hire employees that just do professional development naturally, without explicitly sanctioning it, you'll always have employees who slack a little.