Composer + you, the good, the bad, and the horribly ugly Composer, FPM & gigHUB Night, March 2014

Dan Ackroyd
Independent C + PHP developer, Imagick maintainer. That guy with the beard.

More from Dan

  • Solid Structure

    Decoupling, October 2016

    Dan is going to attempt to explain how to build modern testable application using a DIC container. 

    He’ll also talk about the limits of what can be written as clean code that makes you happy and you should handle having horrible untestable code. 

  • Good or bad? - telling the difference is hard

    It's Not All About Code, July 2016

    A large part of being a programmer is making choices, whether it's what framework to use, what libraries to use or just how to structure code. Every day when we're programming we try to take choices that are good, and avoid choices that are bad.

    But what if actually we're all terrible at telling the difference between good and bad? What if we're all just not very good at a fundamental skill needed by programmers?

    In this talk I'm going to try to demonstrate a couple of common epistemological mistakes that the majority of programmers make, how you can try to analyze what is good and what is bad a bit better, and how to limit the consequences that come inevitably when bad choices are made.

  • Interface segregation; the forgotten 'i' in SOLID

    Clean Code, April 2016

    When people give talks on the "S.O.L.I.D." design principles one ofthe letters that doesn't get enough attention is the "i" - the"interface segregation principle". This talk seeks to redress thatimbalance by going into a bit more in-depth into:

    • An introduction to interface segregation and an explanation of howit make your code easier to test.

    • Why in PHP we need to apply the principle more broadly, to maketypes be more specific, so that code is more reasonable.

    • Me babbling on about emotions, and how good code is boring. Which is good!

  • The Value Case for Unit Tests

    Testing, February 2016

    Do you work at a company where there are not enough unit tests in place and things are constantly breaking? Or maybe you have a client that always wants new features to be delivered as soon as possible, without enough thought about maintaining code.

    How do you persuade people that Unit Tests should be written? And that by writing them you will improve your code quality and make development be easier? And how many unit tests should you be writing anyway?

  • Dependency injection the right way

    Design patterns, September 2014

    How DI makes code easier to write, be more testable, more flexible and generally more awesome.

Interested in speaking?

We're always looking for speakers, so do drop us a line, regardless of your experience, we're all about first time speakers.

If you're looking for ideas, a few of the topics we're keen to hear about are:

  • Debugging & profiling
  • Frameworks
  • Lightning talks
  • Support tools (e.g. phplint, boris, phpsh)