Developer for Laravel, Craft and Go.

Replacing a monolith at Airbnb with GraphQL

Adam Miskiewicz was on the GraphQL Patterns podcast discussing how Airbnb slowly replaced a monolith Rails application with GraphQL. One of the key take aways from the episode is that GraphQL is not all or nothing, you can replace items slowly. Instead of worrying about how the backend resolves the data, focus on the implementation from the frontend/consumer.

Adam references an article and talk by NAME, both are well worth your time. The article, , explains. Accompany that article with his talk at GraphQL summit, there are both packed with useful information on schema designs.

https://youtu.be/pJamhW2xPYw

Listen to GraphQL at Airbnb feat. Adam Miskiewicz https://overcast.fm/+OzkqecbOk



Podcast on the birth of NoSQL and DynamoDB

I subscribe to MobyCast, a podcast on all things Docker and a lot of AWS. Recently, they took a deep dive into the origin and history of DynamoDB.

Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache offer a history lesson on the unique challenges of data at “Internet scale” that gave birth to NoSQL and DynamoDB. How did AWS get to where it is with DynamoDB? And, what is AWS doing now?

These episodes are well worth a listen, even if you are not a "NoSQL" person.

  1. The Birth of NoSQL and DynamoDB
  2. Building a database for internet-scale applications (Circa 1998)
  3. The Birth of NoSQL and DynamoDB (Part 3)
  4. The Birth of NoSQL and DynamoDB (Part 4)





Agile does not mean you don't plan

When following agile, people abuse the "Agile" methodology and focus on being too itterative. 

Agile does not mean you don't plan... - Jason McCallister

I see this often with a lot of companies... "we are agile so let's figure it out later". As an experienced software engineer, this drives me insane. Someone once told me "...10 minutes of planning saves an hour of implementation". Hearing that made me really think and changed the way I tackle projects. 

As engineers, we love to jump in a get started but think about every time that you have started a project with a vague idea - how did your code turn out? Odds are... not that great and you probably had some rather messy code. 

Its easy, I get it. We love to write code, that is why we do what we do. However, its ok to have a larger plan to achieve a strategic goal. Planning does not mean you are not being agile. We know things are going to change during discovery, so plan for change but be clear in your overall vision. I have seen so many projects go from a great idea to fail during implementation. 

If you are still not convinced, do you remember a project that had only a small amount of planning. Do you remember launching the project and then the client asks for a huge change? How did you feel about going back to modify that code, and hopefully you had decent test coverage.

Agile is an excellent way to get down to the nuts and bolts of a product, but it does not mean you should not plan ahead.


Google Spreadsheets and PHP

Recently I had a need to use PHP to interact with the Google Spreadsheets API. With all things Google, it can be a little overwhelming to research. Luckily the folks at Twilio published an article on their blog (by Matt Stauffer) on interacting with Google Spreadsheets, well worth the read.

Google Spreadsheets and PHP – Twilio Cloud Communications Blog


Using macros in Laravel Blade

I stumbled across this by chance, this approach was one I often sought in Twig templates and wanted to try my hand at advanced Blade templates.

Lets say for a second that you have a complex form input, maybe one that contains a lot of divs and conditionals on what to display. Attached is the example I was working with:

This could create the "copy-and-paste" condition that we, as good developers, should avoid.

So whats the best approach to solve this? My first idea was Form Macros. I won't cover this as Jeffery Way provides an excellent tutorial on Laracasts, you can watch here - https://laracasts.com/lessons/form-macros-for-the-win.

The second approach, which was one I felt more comfortable with, was to use Blade itself. Before I started, I looked at the common elements of the form and came up with:

*label

*labelFor

*name

*id

*class

So I created a new directory named "resources/views/_macros". Within the directory I created a new file named "file.blade.php" and pasted the following code:

```php

```

Right off the bat I had few concerns, first I was running a conditional against a Blade variable… I did not bother to dig into the parsing order of Blade because well, if it broke it broke… That would be my indicator.

So I proceeded to remove a working field from the site and using @include, I passed the required variables, like so:

So I reloaded the page with my fingers crossed and to my surprise… IT WORKED! So I uploaded a file, added a little extra to fluff it up and was genuinely amazed.

I was always a little skeptical of using Blade but the more I dive into it, the more impressed I am.