Skip to content

Instantly share code, notes, and snippets.

@gvsrepins

gvsrepins/laracon-2014-notes.md

Forked from andrewdelprete/laracon-2014-notes.md
Created July 5, 2014 02:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gvsrepins/6cee5decb57f32c0d143 to your computer and use it in GitHub Desktop.
Save gvsrepins/6cee5decb57f32c0d143 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
laracon-2014-notes.md

###Jeffrey Way (1) - Bootcamp

Jeffrey went through about 12 subjects one right after the other and gave tips along the way.

  1. Mail Drivers for mail notifications.
1. With Laravel 4.2 it’s easier to use APIs like Mailgun and Mandrill for e-mail notifications. This avoids using SMTP which is really cool.

  1. File Generators for generating schema migrations.

  2. Facades - Basic examples on how to use Laravel’s Facades which is basic sugar for service locations.

1. When using Facades it’s harder to unit test in isolation.


2. Shouldn’t be used outside your transport layer. Like http, routing, controllers.


3. You should Dependency Inject the service rather than utilizing the Facade in your domain / logic layer.


4. Doing it the DI way benefits: You remove the service locator dependency, Less reliance on framework, and easier to unit test.


5. See Facade Docs for method lookup.
  1. Form Validation
1. Depending on the application, It’s okay to put Validation in the Controller. However it’s harder to change and you can have duplicate code.

2. A more scalable way would be to create a class that injects the Validator and then put your rules in it instead. If the Validation fails then throw an exception.
  1. Arrays on Steroids
1. If you're using Laravel’s Eloquent then you have a lot of awesome methods available to you. You can also use the Collection object with any custom Array and have the added benefit on those methods.  Methods like, $obj->push() and $obj->sortBy().
  1. Magic Object Creation
1. Hard to explain this one, but Jeffrey talked about resolving things out of the IoC container and the PHP Reflection API. When you use the Reflection API it will “Reflect” into the class and see if it needs to inject any other methods. It recursively loops through each dependency and injects each class.
  1. Muddy Controllers
1. If you want to figure out what kind of team or developer a person is, take a look at their Controllers. Depending on how much the controller is doing could very well tell that the developer doesn’t know what they’re doing.   


2. If things are very sequential in your Controller method. Extract out into their own classes.  


3. When talking to a business, they really talk in terms of CRUD. You could create a class that reflects what the company says. Jeffrey creates something called a “Command Bus”. Interesting. 
  1. Events 1. "Using commands and events as the driving force for your model allows you to capture business flows in a way that matches how people think.” Have you code reflect the intention and needs of a business.
2. Check out “PHP Hemoglobin” on youtube.com for more info.

3. Name your events in the past tense. “whenAUserHasCancelled”
  1. Behat
1. Is sort of a testing framework, however it’s more of a way to write functionality the way they say it. Testing is just a nice result. It’s a cool tool that actually takes english keywords.

  1. Integration Test and Factories 1. Neat little tool to help you create test content easier.

  2. Gulp 1. Makes a lot of common front end task automation. Like minifying, autoprefixer, less / sass compilation.

  3. Envoy 1. A simple deployment tool that SSH’s into server and runs.

Resource: Jeffrey’s entire presentation is on Laracasts.com… Very good!

###Jeremy Lindbolm (2) - AWS for Artisans

Jeremy works for Amazon (AWS = Amazon Web Services) department.

  1. AWS services each have an API so you can control your resources through programs and scripts.

  2. A huge list of Amazon Web Services - http://cypress-interactive.d.pr/CB4d/1WuQlk8q and a get started video http://aws.amazon.com/getting-started/?nc1=h_l2_cc

  3. I have never used AWS before so it was super new for me. It’s hosting in the Cloud that is not only to host your website, but to split it into services where your files can be hosted on S3, DB somewhere else, Elastic Beanstalk can be used to deploy and manage your app, etc…

Resource: Slides - https://speakerdeck.com/jeremeamia/aws-for-artisans

###Jeremy Mikola (3) - Async PHP with React

Jeremy talked about event driven non-blocking I/Os that NodeJS is primarily known for. React offers the same benefit but for PHP.

  1. Pretty much over my head, but really interesting.

Resource: Slides - https://speakerdeck.com/jmikola/async-php-with-react

###Shawn McCool (4) - Talking Laravel.io

Shawn spoke about simple to complex application architecture. He talked about some of the distinctions between the presentation, services, and domain layers of an application. He also talked about the high-level business policy as it related to how we code.

  1. I found this talk to be one of the best so far. It answered a lot of questions I had about design.

  2. Entities - "Many objects are not fundamentally defined by their attributes but rather by a thread of continuity and identity."

  3. The Active Record Pattern - Each row in a DB represents an entity.

  4. Presentation Layer - Controllers, Artisan Commands, Queue Listeners.

  5. Domain Layer - Entities, Repository Interfaces

  6. Service Layer - Sending E-mail, Queing up Jobs, Repository Implementations… A command bus can be used to connect the Presentation Layer to the Domain Layer.

  7. Register Member Command -> Meat of the Application... Advantages Are: 1. No Business Policy in your presentation layer (controllers)

2. Your code shows intent

3. a single dedicated flow per use case

4. a single point of entry per use case

5. easy to see which use cases are implemented

  1. One Handler Per Command

  2. Flow Review - http://cypress-interactive.d.pr/Ympg/JI8N3ZNI

Resource:

  1. Slides - http://www.slideshare.net/ShawnMcCool/laravelio-a-usecase-architecture 
  2. Books - [http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215](Domain-Driven Design) by Eric Evans.

###Tim Griesser (5) - Demystifying Modern Javascript

Tim spoke as a JS developer in the midst of PHP / Laravel developers. He talked about some of the common mysteries behind JS when it comes to a server side guy.

  1. Debugging in the Browser with JS 1. WORST: Alert Driven Development is not the way to go! I’m learning how to debug better so this was good for me… This is when you use alert(‘message’) in your code and constantly refresh your browser.
2. BETTER: console.dir() is great when logging html entities.  


3. BEST: The best thing to use is debugger; in your code. It will stop the JS process while it’s happening and allow you to look at variables in real time to see what’s available to you. This is the best
  1. The Keyword ‘this’
1. this is what is left of the dot .  

  1. user**.**sayName() - this === user 
  
  2. user.friends.add() - this === user.friends
  
2. Except when it’s not 

  1. fn.sayName()
  1. There are MANY MANY JS Frameworks… He mentioned Backbone, AngularJS, Ember and the new kid on the block ReactJS. He gave some pros and cons of each but always went back to using the best tool for the job.

Resource:

  1. Slides - https://speakerdeck.com/tgriesser/demystifying-modern-javascript 
  2. superherojs.com is a list of great JS resources
  3. Another good resource for AngularJS and multipage Laravel apps https://www.youtube.com/watch?v=QBdudSQ1aLg 
  4. Angular Booter https://github.com/brandonkboswell/AngularBooter

###Ian Landsman (6 lightning talk) - Open Source & Your Business

Ian is the founder of UserScape, which is the company who employees Taylor Otwell the creator of Laravel. He talked about unique ways to fund open source products.

  1. Funding Open Source Products
1. Buy the books of people who write open source

2. Pay for design or marketing for open source products

3. Use the products of the companies where open source developers work.
  1. The other aspect of supporting open source: Code.
1. UserScape supports Laravel by allowing Taylor to work on Laravel exclusively one day a week on Laravel.

  1. UserScape is very small: 7 employees. Less than $1M Revenue. But they throw this awesome conference and encourage Taylor to build Laravel.

  2. Companies can give back to open source by letting their employs work on OSS on company time. One Employee for 1 day a Week is a good start.

###Kayla Daniels (7 lightning talk) - Equality in Technology

Kayla talked about being treated differently because she is a girl. Females want to work in a place that is welcoming, inclusive, where everyone can be treated equally.

###Jeremy Mikola (8 lightning talk) - Talk on Lightning

Just some hilarious comic relief.

###Taylor Otwell (9) - Keynote

Taylor talked about some of the history and the future of Laravel. He spoke about what’s in the upcoming release of Laravel 4.2 and some of the products he has been working on like Laravel Homestead and Laravel Forge. Laravel has since become the most popular PHP project on Github.

  1. Laravel Homestead - is a easy to use Vagrant + Laravel to get started on Laravel projects locally.

  2. Laravel Forge - Instant PHP platforms on the cloud of your choice.

1. Tuned for PHP & Laravel - Framework Agnostic. DigitalOcean, Linode, Amazon, & Rackspace. The stack is the same as Homestead.  


2. Forge has a list of great features that looks very appealing. 
  1. Automated configuration of Nginx domains and sub domains
  2. Quick Deploy - literally push a button to deploy
  3. Easy SSL Setup
  4. Forge Recipes - Save common Bash scripts and run them across your servers at any time. Results e-mailed to you.
  5. Archive Servers - Disconnect and reconnect later.
  6. Works with github.com and bitbucket.com service coming soon!
  7. $10 / mo

Resources: https://forge.laravel.com/ 

###Dayle Rees (10) - Breaking The Mold

Dayle is the author of Code Bright which is probably the top book about Laravel. He has a new company called ParkAtMyHouse. He’s the head of development there.

  1. Questions we developers have when it comes to architecture
1. Where do I put “X”?

2. How do you do “X”?

3. In your projects, what do you do with “X”?
  1. Dayle rips out the Default structure in a Laravel install and starts afresh.
1. Base Class All Things!

2. App structure ends up looking more like a package.

3. The Package ‘Shape’ 

  1. Typical Shape.
  
  2. Framework as a utility.
  
  3. Remaining blueprint for config.

  1. Dayle writes events for anything significant that happens. He passes needed values for later. Puts listeners in their own folder.

  2. IoC share method. First time it’s run it instantiates but ten it will share instead of using make() which instantiates again.

  3. When in IoC container use app->make instead of a Facade.

###Chris Fidao (10) - Hexagonal Architecture

Chris spoke more on the lines of app architecture. Architecture helps reduce stress by keeping our applications maintainable, so making changes is easy in the short run and long run. Any bad decision you make in the start will bite you later. He talked about Technical Debt and how it relates to time on a project.

  1. "Hexagonal Architecture is a way of thinking about how and where you write your code in a way that can stay organized through time. Specifically, Hexagonal talks about “ports and adapters” where different “layers” of code is separated from other layers so that they don’t intermingle too much and make it hard to make changes later.”

  2. There are 5 layers.

1. Core Domain ->
2. Domain ->
3. Application ->
4. Framework ->
5. Outside

  1. Every layer is an adapter for the layer inside of it. It works from the Outside In and the Inside Out. 

  2. Outside Layer = Comes from Web, API, CLI, Queue, or Event Handler

  3. Framework Layer = All the code that helps you do stuff but isn’t your application.

  4. Application Layer = Orchestrates the domain layer. Implements the domain logic.

  5. Domain Layer = The logic behind the application. There should be boundaries between the two. It defines the interface for the application layer to talk to.

  6. Identify the aspects that vary and separate them from what stays the same.

  7. Key Point: Encapsulate Change.

Resources: 

  1. Slides - https://speakerdeck.com/fideloper/hexagonal-architecture

  2. Books - http://www.amazon.com/Head-First-Design-Patterns-Freeman/dp/0596007124

###Greg Bauges (11) - Devs & Depression

A very serious talk about mental illness. Greg is BiPolar and ADD.

  1. Sleeping a lot and avoiding commitment may be a sign of depression.
  2. He talked about the differences between the two types of bi polar.
  3. Symptons of ADD 1. Hyperfocus 2. Social Isolation 3. Racing Thoughts 4. Irregual sleep patterns 5. thoughts of grandiosity

Resources: 

  1. Site http://www.bauges.com/depression

  2. Video: http://vimeo.com/72690223

###Igor Wiedler (12) - Abstract Machines

You just had to be there. Mind Blown. Can’t explain.

###Cal Evans (13) - Going Pro

Cal spoke about principles that make a “Professional Programmer”. He’s sort of a motivational / inspirational speaker that has been around the block a few times.

  1. Being a professional programmer is not a skill net, it’s a mindset.

  2. Getting paid is not what makes you a professional programmer.

  3. D.U.C.C.H.T

1. **D**uct Tape Master - Any person who can take two components and stick them together to make something happen  


2. **U**nderstanding - Understand the technologies that you are using, the stack that you’re going to deploy, and the technologies that your client is going to want you to deploy. Your client is an expert at the problem, not at the solution. You’re the expert. You have to understand what the proper solution is and why.  


3. **C**urious - Get involved and be curious about technologies you use. You don’t have to master every tool but you should know what they are and when they’re appropriate… Start a project just to experiment. Only goal is to learn one thing.  


4. **C**ommunicate - Learn what language your client communicates in. Not everybody speaks programmer.  


5. **H**onesty - Be honest about how long their project will take. Be precise. Break your tasks down and fully understand what is involved and how long it takes you… Be honest with your skill set… Explain clock time VS. Calendar time. 40 hours doesn’t mean 1 week, it could be a month.  


6. **T**eam Player - If you’ve never been a developer, you have no business managing developers… Cal says he rather have 4 mid level developers on his team than 1 amazing lone wolf… If you call developers “resources” then I will call you “overhead”.  

7. Being a pro doesn’t have to do with your mad skills, but with solving problems.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment