Brushing up noeldemartin.com

I've just finished upgrading the website to Laravel 6.0 using Laravel Shift. The previous version I had running was 5.7, so I've had to run 2 Shifts: 5.7 to 5.8 and 5.8 to 6.0. The whole process took me about an hour from start to finish; from creating the account to deploying the changes. I had to pay a total of 22$.

Overall I'd say it was a good experience. The Laravel upgrade notes indicate that this process should take about an hour for each version, which makes it a total of 2 hours plus testing, deploying, etc. So I could say I saved myself an hour here.

Now, there are some things to keep in mind.

First, Shift gets more expensive the older your Laravel application gets. This means if I stay up to date from now on, doing this will be cheaper.

Second, my website is a very simple application, it does little else than CRUD operations and there is almost no business logic (publishing posts and tasks, that's it). On the one hand, this means I could have done the migration myself without too many hurdles, which makes automating this less valuable. On the other hand, it's easy for me to trust the automation without looking at the changes, because the application is so simple that it was easy to see that nothing was broken. I guess it all comes down to how much you trust your tests, and if you do, Laravel Shift is awesome. (If you don't, you should reconsider why not and fix them.)

There are also some things I would improve.

The way this works is that Shift opens a PR in your repository with the upgrade changes, and it includes some comments with additional details. I found some of the details lacking information or too vague. There was for example one comment against using strings for class names, but it didn't indicate which files had the problem.

Something else I'd improve is the access to the Shifty Coders community. This is a Slack community that is recommended on the PR in order to get help, but I was not thrilled to learn that it's a paid community. I don't have problems with paid communities in general, but in this case when it's being suggested as a place to get help using a paid service, I don't think it should be. Specially since I'd probably only use it to get help with the service. If I'd be interested in a community for all things Laravel, there are others that may or may not be better.

In summary, I'm happy with the experience and I'll probably use it again. I'm looking forward to test it with a bigger project to see if my opinions holds up.

As a follow up to yesterday's Shift upgrade, I've been looking at the upgrade notes to see if I didn't miss anything. I think it's a good idea to take a quick look, but I didn't find anything that hadn't been covered by Shift, so all good. Usually, I also watch the What's New lessons on Laracasts, so I'm pretty much covered on all sides. Of course, I don't think all of this is necessary in order to upgrade, Shift should suffice, but I also enjoy learning what's going on in Laravel to keep up to date with new features.

I've also been talking with Jason McCreary, the creator of Laravel Shift, and given him some feedback on the service. He's been very helpful on solving some of my doubts and he's still working on improving Shift, so I'm sure it'll become even better. One of the things I learned from him is about the Shift configuration file. This is a file you can have in your repo to configure how Shift behaves, and it can be very helpful to customize some of the automation.

With this, I consider my upgrade with Shift complete. Now I'll try something else I'm very excited about: Laravel Nova.

These days I've been playing around with Laravel Nova.

My initial impressions were great. The installation process was a breeze, and I had a functional dashboard within an hour. The work involved to get there is fairly minimal, you only need to install Nova through composer and create a Nova Resource for each Eloquent Model. In order to learn the basics about Nova, I'd recommend watching Taylor's Keynote at Laracon US 2018. That's all I had seen before getting started and it was enough (along with the docs of course). There is also a series on Laracasts, but I have to say I didn't enjoy it too much. Maybe because it wasn't Jeffrey Way doing it?

After the initial integration, I spent some time trying some advanced features and customizations. I didn't find the customization as easy as I expected, although I have to say I didn't spend too much time on this because they were only some nice to haves. Fortunately, most of the things I wanted to do were already available as community packages. I used these two: a responsive theme and a url field. More packages can be found on novapackages.com.

But not everything was covered by packages. I write my content in markdown, and this is something Nova already supports with a Markdown field. However, this field stores the markdown on the database and renders the html with javascript on the frontend. In my current setup, I am creating the html on the server and storing it to the database as well, so there are two attributes affected by this field. I couldn't find an easy way to customize the markdown field to do that (read the next comment for an update on this). So I decided to register model listeners for saving events and update the html attributes before saving the changes. I could also have converted the markdown to html on each request before rendering the views, but I decided to keep my application code unchanged and do all of this on the Nova side. I had to do this with multiple resources, so I used a boot method similar to the one in Eloquent models. Check it out on this gist.

In summary, it's easy to integrate and it can save you a ton of work. I am already writing this from Nova, so I'd recommend anyone to check it out.

I wanted to write an update on my last comment. After my initial integration and writing that comment, I watched Taylor's keynote introducing Nova once again. At the end of the keynote he mentions that field classes can override some methods in order to customize the behaviour. Turns out, there is already a method that I can use to customize the Markdown field, and that is fillAttributeFromRequest. I extended the base Markdown field class and I've overriden that method to set the rendered html attribute as well. So now I don't need to use the model events for that (even though I'm using them for other things).

So yeah, like Laravel itself, it's a good idea to look into the source code of Nova when you're trying to customize some part of the framework. That's acutally something that has taught me as much, if not more, than reading the documentation for Laravel.

I recently had to buy a new laptop, and I've been having some issues with it. At first I thought it had something to do with drivers, because it's not unheard of to have issues with nvidia in linux. But after contacting the ASUS support, it looks like I've got some defective hardware and I'll need to send it back. The lesson to learn here is that I shouldn't assume issues always arise from me using "alternative" operative systems; hardware can be defective too. So yeah, I've wasted a bunch of time configuring a defective laptop and I'll be laptopless for a while. But I expect to continue doing some work at home where I can plug my old laptop to the TV (the screen is broken and I don't have a monitor).

But, I could get some things done! (I wouldn't be writing here if I hadn't). Some time ago, I used a site called webpagetest.org to evaluate how I could improve my website, and I applied some of their suggestions. One thing I did was to refactor the way I'm using fonts. I was using googlefonts, but I wanted to get rid of those so that I don't give Google any of my visitors' information anymore (I don't use Google Analytics, nor any other analytics for that matter). I also removed a lot of glyphs from the font I'm using in the header, since I only need a couple of characters and I was using the whole font. I reduced it from 35kb to 4kb, which may not seem much but every byte counts (I used FontForge to do that). I've also been working with nginx, and I've added some new commands to nginx-agora. I optimized caching static assets using the expires max; directive, and I turned off access logs for visitors privacy.

Finally, I did something I've been pondering for a while. And that is setting up a Google Search Console account (previously called Google Webmasters). The reasons why I had my doubts are manyfold. I don't want Google to be everywhere, so I will do whatever I can to keep my vistors' information safe from them. Search Console doesn't interfere with my visitors, so I may as well see what they have to say about the website. I don't care about SEO in the least, but I care about my website being well-formatted and performant. I already know one of the suggestions they'll give me, to use AMP for my blog posts. And quite frankly, on that one they can go fuck themselves.

It's taken almost a month but I've finally got my new laptop, and it's working like a charm. The laptop is Asus TUF FX504, and even thou it's a gamming laptop, I use it for development. I had my doubts about it, but so far I don't regret it.

I've continued with the improvements I had pending for the website, this time they were UI related. I've upgraded the TailwindCSS version given that 1.0 has been released, and I've also set up PurgeCSS for a smaller bundle. Together with other improvements (removing the title font, removing functionality that's covered with Nova, etc.) the JS and CSS assets are now very light, less than 100kb before gzipping. Which would be more impressive if it weren't because this website has almost no functionality, being a content site. On that note, I've also applied many ideas I got from reading Refactoring UI. Maybe the most impactful has been reducing the width of almost everything on the site for readability. The site is now taller, but hopefully easier to read and browse.

One last thing I did was unifying the navbar for mobile and desktop. On desktop, the navbar is fixed under the header. But in mobile it's a drawer toggled with a button in the header. I had this implemented with two elements whose visibility was toggled depending on the layout. I decided to change it to a single element and use CSS "magic" to change the styles depending on the layout. I was inspired to do this looking at CSS Zen Garden, and the end result is a single nav element. Which should be better for screen readers and accesibility.

I've stored some snapshots of the website in the wayback machine, so you should be able to compare the live site with the archives to spot some differences.

Today I've finished one last iteration where I've updated the home page and reviewed the copy in multiple pages. I have also added a footer and a new section, where I explain the technologies I've been using.

I could continue iterating, and I am not 100% happy with some of the current design. But I'll stop this task here because it's dragged long enough. I'll probably continue iterating at some point in the future, but that's it for now.