Lemon Bytes

Husband, Father, Software Engineer and Steelers fan

Adding PATCH to LemonRestBundle

Work on LemonRestBundle continues, last night I merged in support for PATCH. This is an interesting beast because there are some strong opinions on the proper way to implement PATCH in a REST API. Initially I assumed I would just avoid it rather than subject myself to the judgment of poor implementation. However, the more I researched PATCH the more I realized that I wanted to add it, and furthermore the strong opinions were largely academic in nature. The JSON Patch specification is rather powerful but also complex, I’ve yet to find a consuming client that actually supports this standard. What I see a lot of is more akin to the JSON Merge Patch specification, and this is exactly what I’ve decided to add. Truthfully the bulk of the work in my implementation happens in JMS Serializer. I need to do more extensive testing on object nesting but the basic implementation works right now. One issue to keep in mind is the current setup requires you to specify the object id when in the PATCH request. I hope to fix this in the future, but for now that’s the requirement.

I’ve also recently added the ability to customize the Criteria object for searches.  The Criteria object is basically a collection of the query parameters and it gets used by the ObjectManager to add filtering to the findBy() command used for making collections of a given resource. Out of a set of query parameters the default implementation separates out some data for limit, offset, order by and order direction and then provides those in a standard way to the ObjectManager. The limiting factor in the initial implementation is that you might not have liked the fields I was using for limit, offset, etc. Customizing the Criteria object gives you full control over how this is handled. You can read more about how to configure this in the bundle’s documentation.

I’ve been experimenting with generating Swagger docs within my bundle. I would expect this to materialize in the next week or so.  The technical details are already available to generate the docs, it’s the descriptive data that isn’t there yet and I’m still evaluating the best way to make that possible. Ultimately I’d love to have the bundle help it’s users generate documentation for their APIs, eliminating yet one more detail in the management of a REST API.

Last but not least there I think it’s safe to expect support for versioning, again this will largely be driven off of JMS Serializer’s version exclusion groups.

Work on the bundle continues to move forward. Several folks have made contributions, all of which I am really grateful for! If you have a suggestion, recommendation or spotted a bug of any sort please open an issue over on GitHub.

Demoing LemonRestBundle with ng-admin

tl;dr You can try out LemonRestBundle with ng-admin here.

Last week I shared that I was working on a Symfony 2 bundle that would create REST end points from Doctrine entities. I’ve been continuing to work on that bundle, adding features and flexibility and I decided to re-evaluate the way I was demoing it. The truth is that I didn’t want to sink a lot of time into writing a demo, but I also want to do a show more functionality than just pulling down some objects from and dumping them to a page. What I want is to show the full REST life cycle, getting, searching and saving objects to an api. Fortunately there’s a really great tool out there that plugs into a REST api and does just that! It’s called ng-admin and it’s from the folks over at Marmelab.

For those that aren’t familiar with ng-admin, it’s a tool written using Angular and it allows you to easily wire up a “stock” UI for a REST API. Like my own project, it’s opinionated and convention oriented. Quite honestly it’s a pretty cool tool. So I’ve hooked it up to a symfony standard application with the LemonRestBundle and configured some entities to match Marmelab’s own demo. I also pulled the sample data down that Marmelab was using and stuck it in a sqlite database. The database resets every minute, but it’s enough time to create a post and edit some comments and see LemonRestBundle in action. The really cool part is when you take a look at the demo app’s GitHub repository and realize it took three Entity classes to make the whole thing happen.

I’ve deployed the demo over at OpenShift so you can take a look and try it out for yourself. You can also clone the demo app from GitHub, run composer.phar install and try it yourself!

Links to check out:

LemonRestBundle for Symfony

For a little while now I’ve been working on a bundle for Symfony to easily create REST apis for Doctrine entities. My goal was to be able to create a REST api with nothing more than a Doctrine entity and it’s metadata, including custom metadata from bundles like JMS Serializer. I wanted to invest very little time in the actual api part, and get to writing applications that used it. I’ve hit this wall before, and inevitably what happens is I make a valiant effort at rolling a REST api and then get distracted or bored and walk away leaving the project to rot.

Recently I was resurrecting an older project and wanting to do right by it and decided I could mask a lot of my database worts by leveraging some of Doctrine’s more advanced features. Specifically I added custom types to ensure I had good data structures, leveraged some lifecycle events and implemented Doctrine 2.5’s recent addition of Embeddables. I had also added a bunch of validation to my entities using Symfony’s Validation component, so they were well defined and could be validated easily with meaningful responses when things weren’t right. I wound up with a clean set of objects that did what I wanted well, but there was one problem, I needed an api! Having been down this road before I wanted to solve my problem for the last time, or at the very least make the problem more interesting to solve.

Recently I have been playing with Knp’s JSON Schema bundle and this was in part my inspiration to make something that was magical. I don’t mean magical in the buzz word sense (okay, maybe I do). I mean magical in the highly opinionated, convention driven sort of way. My solution needed to just work(tm). The pieces were all there, and as I mentioned earlier the bulk of the tooling already existed, specifically great serialization, easy validation, reliable content negotiation and of course the graph traversal of Doctrine itself.  I just needed to get it all hooked into the request/response process of an api. Thus begot my very own REST bundle for Symfony 2.

Now hold up, I know what you’re thinking… Symfony already has a REALLY good REST bundle from Friends of Symfony, doesn’t it? This is very true! That is an excellent bundle, it’s high powered and very flexible. Mine is not. In fact it’s not even intended to be. If you want HATEOAS for example, FOSRestBundle is the right option for you. If you need to customize the POST/PUT processes or alter extensively the behavior of your GET actions, then FOSRestBundle is going to be a far better option for you. If you want to use Propel or Mongo (though that may come in the future for mine) or any other data source besides Doctrine ORM than FOSRestBundle is the better option for you. If you are using Doctrine ORM and want to write as little code as possible while getting some REST endpoints, than my bundle might be the better option for you.

Enough chatter, take a look at the fixtures included in my bundle and you’ll see some very simple examples of what sort of metadata driven modeling I had in mind for this project. I have a pretty extensive functional test that shows how the bundle works. I’ve also built a simple example application using this bundle that you can take a look at and see the bundle working. Well without further delay, I’m really happy to share with you LemonRestBundle, documentation included! Feedback is very welcome, feel free to drop me an email or shoot me a message on twitter.

Why Symfony 2.5 is important

Symfony 2.5 was released on June 1. I’ve been following blogs and listening to podcasts about the release and there are a lot of really awesome additions in this release. But there is one feature in particular that I don’t believe is getting enough attention and deserves some.

Back in April I wrote about my frustration with Symfony & Absolute Paths. I was excited to see in May that this concern found itself into an official GitHub issue and PR and that it might get resolved in a future release of Symfony.  Well it has, and burried under the notes for 2.5 RC1 is this, “bug #10894 [HttpKernel] removed absolute paths from the generated container (fabpot)”.

Quite frankly, this is huge!  After my post in April I hacked together what I was calling a PathlessKernel to work around this issue.  I basically regex’ed out the application root from the container. In my opinion this was an inelegant solution and thus I chose not to share it. The fix in #10894 is far superior and allows for the regenerating of cache in a CI environment before deployment without all of the path chaos previously created when dumping the container.

This is a big win for Symfony as it makes an application build artifact truly portable!

Review: Extending Symnfony

Extending Symnfony by Sébastien Armand is a tutorial-style introduction to a variety of the ways that you can extend a Symfony 2 full stack installation. I’m a big fan of Symfony 2 and I’ve done a fair amount of app building with it, so I was interested in Armand’s book and seeing what new things I could discover about hooking into sf2.

The book is filled with code samples, far more than you’ll find in most other technical books. Most of these code samples are also complete, which anyone who has traversed the official Symfony 2 cookbooks will greatly appreciate. Unfortunately, these code samples sometimes cross pages in inconvenient ways, and none of them include syntax highlighting which can make it hard to read at times.

Armand tackles six (sort of eight) areas of Symfony 2 development where developers can tap in and extend existing functionality of Symfony 2. First and foremost he kicks off his tutorials with covering service definitions and listeners. These topics seem like they could have been separate chapters to me, but nonetheless he does a good job of giving real world examples of how to tie these things in. He especially does well with event listeners – the secret weapon of the Symfony 2 stack (in my opinion anyhow).

Armand’s approach to extending symfony is project-based, meaning that through the book you’re working on building an app that handles some details for meet ups between users. You can think of it like the old Symfony 1 Askeet tutorial. This is a huge advantage of Armand’s book over other Symfony 2 texts you’ll find in the wild. Actual applications create context and drive home the concepts. As an added bonus, in this book you are NOT building yet another task manager!

The Security chapter covers some of the more difficult areas of Symfony 2. Anyone who has dealt with Security in sf2 knows that, while extremely powerful, it can also be extremely challenging. Armand’s examples are helpful, especially as he tackles an OAuth implementation. Armand uses the Friends of Symfony UserBundle to get going, but unfortunately didn’t cover with too much depth getting started with this super handy bundle. The examples in the book are priceless, but I look forward to future revisions that cover the new SimpleAuth implementation in Symfony 2. The only other thing I wished Armand would have covered was securing an api with tokens and a custom user provider for doing this. He shows how a cookie can be used with an event listener, but truthfully there are better ways of tackling this problem in Symfony 2 that are more consistent with its security model.

One of the most valuable chapters in this book is the Doctrine chapter. Doctrine 2’s official documentation lacks a lot of context. By being a project-based tutorial, Armand actually shows you how to write a custom data type, custom DQL function, and a custom filter, rather than stumble through the Doctrine 2 docs and hope you got close. This chapter in and of itself is a valuable resource for those times when you need to do these things.

The final chapter discusses bundles briefly. This is one area of the book I felt could have been fleshed out a bit more. Armand covers the basics, but part of me felt like this chapter almost belonged at the beginning of the book instead of the tail end. The other thing that was missing from this chapter was bundle inheritance which, while a tricky subject, is a huge part of extending a Symfony 2 application.

All in all I think this is a solid book on tapping into some of the more powerful features of Symfony 2 and it’s counterpart Doctrine 2. The book is at times a little oddly organized, but the code samples and tip are worthy any web developers time. If you’re looking to dive into some of the things in the book’s table of contents get yourself a copy and profit from Armand’s tutorials and extensive code samples.

A Review of Pley & Renting Legos

I recently decided to signup for Pley, a service that supplies lego sets by mail for a monthly membership price.  They advertise that you’re safe to lose a piece or two and that the kits are always sanitary using their special FDA grade process.  Unfortunately I found both of these claims to be false.

First off let’s set the record straight, I’m an adult Lego geek. That’s a technical term, you can check me on it. As a kid I had a vast array of sets and spent countless hours constructing my dreams. Then I went to High School, College and got married and had mostly forgotten about Legos.  Until I took a job where I was working on the hosting infrastructure used by the Official Lego Podcasts, like this one.  Suddenly I had an excuse to play with Legos again, it was work related after all…

I’ve collected a few sets as an adult, and I fully admit to playing with them from time to time.  I’m not ashamed. When I saw Pley I thought it could be the perfect life-as-a-service for my late night hobby.

I went through the trial and the first set I got was a total bust. The Desert Skiff came in the mail and I started piecing it together.  Normally I try to avoid the directions as much as possible, as that adds to the general fun of the puzzle.  But on this one though I had to pull out the book. This probably sounds a little crazy since it’s only a 213 piece set, but hear me out. As it turns out the set was missing pieces, to the tune of at least 10! I finally couldn’t finish the set because there were so many missing. I logged online an reported the missing pieces and sent the set back in.  I admit that out of frustration I didn’t pull everything apart. I hadn’t heard back from Pley until this week when they sent this email to me.

Hi Stan,

We hope you are enjoying Pley. We have received your set today. Thank you!

To keep kids happy, we ask all users to disassemble the sets to individual pieces so that each child has the same building experience with no sets arriving partially built.

Here is a note we received from on of our Pleyers:

Tal's letter:can you separate piece

We appreciate you taking a few extra minutes to separate each piece so that other children can enjoy the set equally.

Thanks for Pleying!

The Pley Team

I’m a little more than flabbergasted. I didn’t get any replies when I filed a missing-part list! On their website they say, “Lost a piece? No worries. We won’t charge.” What they don’t say is, “The next guy might be out of luck though!” Furthermore, if their process is so clean how did this kid Tal get the set still stuck together? How do they know I didn’t stick a booger between those blocks?  And really what are they doing sending this kid’s letter to me? Surely this is some kind of privacy violation!

The thing I really miscalculated though was thinking that renting one set at a time would somehow pacify my burning desire as a Lego-master to mix and match multiple sets. There simply is nothing better than owning your sets, period.

Unfortunately I just can’t recommend this service.  Yeah, it’s partially out of bitterness, but I also feel like I’ve been lied to. So keep buying on Amazon, or Target or wherever it is you get your Lego-fix and steer clear of Pley!

Technique: Beard Prep

Originally posted on Shave with Swagger:

My shaving technique is the combination of several ideas and steps that I’ve gleaned from various websites and videos. Today I’ll share my beard prep steps.

One of the important aspects of wet shaving with a double edge razor is making sure your whiskers are ready to be cut. You don’t just go at them. They’ve got to be prepped. Made ready. They need to be gently brought to that state where they wait with eager anticipation for your blade to lop them off. Here are my steps.

  1. A hot shower. In addition to the primary benefit of cleaning your body and making you smell better, a hot shower is an opportunity to wash your face with soap and hot water. The hot water opens your pores and washing your face softens your whiskers, making them pliable and compliant in the cutting process.
  2. Don’t dry your face. When you dry…

View original 255 more words

Follow

Get every new post delivered to your Inbox.

Join 1,274 other followers