Unconventional

I started a new project late in 2014 which I knew would be fertile ground to keep pace with the what's happening in Laravel 5.  It's been a great learning experience merging in changes from the upstream Laravel project branch as they happened. The keen observer might have noticed however that Taylor made a commit on December 4th that "broke" support for packages designed to target Laravel 4. @Omega_ ehhh maybe… i’ll see how it shakes out… need to finish that up next week — Taylor Otwell (@taylorotwell) January 1, 2015 Patience is key, so I was happy to continue waiting for the next great thing . In Laravel 4, packages allow their configurations to be overridden per environment.  A package can ship a default configuration which can then be copied into the project as a template to be combined with the original's settings at runtime.  Think of it as a really tricked out  array_merge_recursive . By removing ServiceProvider::package , what's being co...

A friend of mine who I occasionally help with development tasks came to me the other day asking about starting a project which would involve leveraging an API. Given that I develop APIs and domain architecture, this seemed like a pretty good fit for my talents.  I can produce the business logic and a simple chrome extension that talks to it and then we can explore further opportunities later, knowing that everything has been nicely abstracted. I've coded against a few public APIs in my time for various things ranging from social media to push messaging.  Although each time, I'm always left feeling like what I did was never a first-class citizen in my project.  In many cases with APIs, you're only leveraging the external model, but in the case of my new project, I actually plan on "extending" it... Read on if you're interested in any of the techniques involved, including repositories and project structure. Extension Defined When working with an extern...

I had the great fortune of being sent to OSCON by my employer (we're hiring!) this year.  On top of getting to hear from lots of like-minded developers and learning about technology I might not have otherwise considered, I also managed to score some loot!  The most notable of which being a Surface Pro 3 which I had been coveting since their release, but had lost interest due to very steep prices. Getting it was actually an interesting process that I was perfectly okay with playing into because we're all at OSCON to have fun and learn. Being their main source of revenue, it's important that Microsoft fend off the impression that Windows is developer unfriendly.  So, the overall gist of Microsoft's booth at OSCON this year was to remind people that you can in fact develop using free and open source tools on Windows, a non-unix.  ( Curiously, I have been saying since the 90s that FOSS would be the norm and Microsoft's 180 on it of late is just more writing on the wa...

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...

Just a small blog post for developers trying to make heads or tails of how to work with OpenGraph, self-initiated likes and preparing web sites for facebook integration: These two pages seemed to give me the clearest bird's eye view of things: Like Like Button Migration I'd file this under "You didn't ask the right question!" , sometimes documentation fails to establish the basics and this is one example of that.

A popular feature in Rails called "mixins" came to PHP a while back under the name "traits".  Traits let library developers give you a lot of functionality with little to no effort by injecting code into your classes that runs as if originally authored in them. Just toss a line of code into the class you want to augment and you're off to the races. The one snag I found when using traits however is that they don't participate in any kind of type system.  If desperate enough, you can use reflection to pull out whether a class has one applied or not, but that's only half the battle and a lot of work each time. This puts me in a slight bind when I'm interacting with classes using a trait I've made as I have no way to type check or hint them in. But then it dawned on me... interface MyInterface { public function thisMethodIsImportant(); } trait MyInterfaceImpl { public function thisMethodIsImportant() { return "Thanks...

Are you looking for a way to resolve things like translation, validation and config from the Laravel IoC? Look no further! Make yourself a service provider (whether in a common tools package or in your project) and add the following to it in the register method: $this->app->bind('Symfony\Component\Translation\TranslatorInterface', function ($app) { return $app['translator']; }); $this->app->bind('Illuminate\Config\Repository', function ($app) { return $app['config']; }); What you've done is mapped all the string-registered services to their most abstract but also most specific types.  Config is a good example of where you should be binding the class name and not an interface because the only interfaces it implements are ArrayAccess, and that's obviously wrong! :) Happy constructor-injecting!