GitHub is My View Source

When I first started learning web development in earnest, (beyond basic HTML), the community college I was attending was still teaching Dreamweaver as de facto method of building a site and using Photoshop and tables based layouts. Meanwhile I had launched my first blog with WordPress, fresh off the 1.5 release that brought full themes, XHTML and CSS. Reading blog posts on the subjects was basically the way I learned those skills. And viewing the page source of the authors writing those posts.

Fast forward to 2016, and I still view source. More often than not now, I’m learning from GitHub repositories. Which is why finding the Octotree browser plugin was such a find. Rather than having to navigate back and forth inside a repo, you get a tree view of the files to the left of the browser window. If you find your self using the back button and navigating breadcrumbs, I highly recommend checking it out.

Performance is a Feature

I spent last evening making the necessary tweaks to this site to get a perfect 100% score on Google’s
Pagespeed Insights. I understand this is just a personal site, but at the root,understanding how to make this site fast will translate to helping bigger projects keep an eye out for potential bottle necks.

Which is why when Aaron Gustafson tweeted this posts headline, it caught my eye.

Either way, you could do much worse than to make your bit of the web fast.
Peter Chamberlin

The context was more broad and I believe directed towards larger sites, but it has to start somewhere.

Also, I plan on sharing how I implemented the changes to get to 100%, specifically the critical CSS.

Customizing Atom Editor

I doubt anyone who writes code for a living or tinkers for that matter hasn’t spent more hours than they’d care to admit tweaking their editor of choice. Suffice to say, I’m in that boat all to well.

My current editor of choice is Atom. It’s open source and more than fits the customization itch.

Aside from deciding on which packages to use (I’ve
starred the ones I use) the other element I’ve gone back and forth with is theme & syntax UI. I’ve long been a fan of both Solarized Light and Dark, but have finally settled on Atom Dark and Oceanic Next. I can also recommend Oliver Pattison’s Newbound syntax themes My dream font is Operator Mono, but until I can justify the purchase of that, I’m using Input.

One tweak I just discovered is for adjusting the font size in the panel, or the sidebar. I’d been able to easily make the font larger for code/markdown, but sometimes had to break the readers out to discern what file was what in a nested folder. To the rescue I found atom-panel.tool-panel for just that. I’m currently using 1.4em. Mind you this is on my old 11 inch Air. I’ve not had as much an issue on the iMac.

Another tweak I’ve added to my custom styles.less file is to italicize attributes. I’m also a fan of italicized comment blocks, which is included in the snippet.

atom-text-editor::shadow{
     .entity.other.attribute-name {
         font-style: italic;
     }

     .comment {
       font-style: italic;
     }
 }

I’m sure as I expand my development world, (I have a goal to learn python by Building a Twitterbot ) I’ll continue to tweak Atom, but for now, I’m as close to happy with an editor as I have ever been. Feel free to share with me on Twitter @miklb your tips and trick.

Dogfooding

Last night I switched over the theme for this site to a project I’ve been working on the last moth or so, Jekyll-IndieWeb. While I have different design ideas, until I find other users interested in using it, I knew I needed to work out any kinks. I also wanted to have better microformat support until the design changes. Thus
dogfooding.

I will write more about the project once I have more documentation (and work out any more said kinks), but the gist is I wanted to provide someone new to Jekyll with a desire to be part of the
IndieWeb a solid starting point. I rely heavily on the _config.yml file for options a user can set – profile pic, social media links, choice to include display of webmentions – to quickly get a personal site up and running. The biggest hurdle for me was providing a minimal design that was unopinionated yet still aesthetically appealing. Anyone familiar with HTML & CSS can easily build upon or modify it, but if not, it shouldn’t look ugly.

This has been the first solo project I’ve embarked on that was meant for public consumption from the start, which in itself has been a learning process. Now I just hope others can find it useful in some way. If the project interests you I encourage you to try it out, open any issues in the repo, or reach out on #indiewebcamp IRC, I tend to hang around there most days.

Embracing My Suckiness

Some know I used to cook for a living. I’d like to think I was pretty good at it too. I started before the Food Network and all the other cooking shows on TV (save for old Julia Childs and Jacques Pepin shows on PBS and the like), before the internet blew up. Cooking in Tampa was almost like being in a vacuum. You’d see what your peers were doing, maybe find a little time to travel to Miami or New Orleans, but otherwise, we were left to our own curiosity, a few books from some of the chefs on the cutting edge (Mark Miller and the staff at Coyote Cafe, Norma Van Aiken and his contemporaries like Allen Susser & Mark Militello) and the occasional Food & Wine article.

We explored other cuisines via ethnic dining, scoured Oceanic Market for Asian ingredients, the markets of West Tampa for authentic Latin/Caribbean staples, and the open air markets outside the commercial produce market. We were then left to our imagination, creativity, and abilities to marry flavors together.

That was kinda like how it was when I first started building websites. You’d look at someone’s source code. Someone might have written a blog post, or shared a tip in a forum somewhere. You bought Zeldman’s book on HTML standards, or Andy Budd’s CSS Mastery. It was a path of discovery and learning.

Now, in this “age of information”, we (I), am bombarded with all of the latest tricks and best practices, cutting edge designs and techniques. The external pressure to live up to these can be overwhelming. I’m no longer experimenting and discovering on my own, I’m drowning in information. It’s like having an elevator straight to the top of the mountain without experiencing the journey (I think that’s a paraphrase of something I read once about doing LSD, but I digress.)

So what I’m finding is that I’m a deer in the headlights, afraid that I’ll be judged for not using the latest markup techniques. That someone will see my code and think I suck. And rather than embrace my suckiness, learn from it, I freeze. I stare at blank pages in my text editor. Meanwhile, new and more information continues to bombard me from every angle, and the cycle perpetuates.

Today, when I cook at home, I’m not worried about having all the fancy ingredients or flashy sous vide machine. I’m confident in my skills and know the finished dish will look appetizing and taste better. Or, I might just miss the mark, but will recognize what I did wrong or forgot, storing it away in my memory bank or nowadays, jotted into a text file for the next time I make a similar dish. That’s not to say when time permits I don’t use those fancy ingredients or make my pasta from scratch but a good meal shouldn’t be passed up simply because I didn’t have artisanal cheese and didn’t make my pasta from scratch.

So while I struggle to reboot my personal site and convert it to Jekyll, I need to recognize that I don’t have to follow every new trend. So what if it wasn’t built in Sass. The work I put into making it responsive, and FAST is more important in the long run. There are plenty of sites/devs out there that have well structured Sass directories and all the right mixins, but load slow as hell. There is plenty of time in the future to revisit converting it. The end goal for this site isn’t about being a Sass master, but an outlet to share my thoughts and experiences on the web. Why create an artificial hurdle?

Which also means I need to document my failures, as well as successes. Whether that means publicly, or internally. Not only document them, but celebrate them. I need to reconnect with that ambitious kid who would spend every waking hour in the kitchen experimenting, enjoying the journey. Thus starts my journey of documenting this phase of my site.

Technology Fatigue

A piece at A List Apart today struck a nerve with a lot of developers today, myself included (if I can really call myself a developer these days.) Overwhelmed by Code touches on the constant bombardment to developers from new technologies popping up seemingly daily. The author discusses

It used to be that knowing CSS and HTML was enough, then jQuery came along, then responsive techniques, then Node.js and then Angular, Ember, etc., etc., etc. That list, right there, it tires me out.

To that I can completely relate. When I stumbled into making websites, they were still teaching how to use Photoshop and tables to build sites at my local community college, not pure CSS. The big revelation at A List Apart was Faux Columns. So fast forward 10 years, take a sabbatical for 2 of those, and you can imagine how overwhelming stepping back into grunt, gulp, coffee script, node and Luce1 is.

What do I want to focus on, what do I love about the web? What do I actually want to learn, versus what I think I should learn.

So if I am to do more than dip my toes back into the world of building websites, I too need to focus on what I I think will best benefit me professionally, not try and keep up with kids.

On Twitter Clients and Their Change in TOS

Update: The plot thickens. Sean Coates pointed out on Twitter this morning that the Twitter API announcement has been pulled, with no obvious response. Most of the mailing list message is still available in an article in the Guardian.

First, I’m not a developer of software. I make websites. I use Twitter. A lot sometimes. I have found the reaction to Twitter’s curious announcement in the change in their terms of service interesting. Granted, most reactions I have read are from developer types, so it may be biased. The sentiment could be summed up in a tweet I saw today, “Twitter: from #dickbar to #dickmove”. That basically Twitter added a new “feature” in their most recent mobile app that absolutely no one liked and users were abuzz with suggestions for other clients. Rather than listen to these users (granted, they did release a minor update that apparently mitigates to a degree the trending bar, coined by Gruber the dickbar) they simply decided to post to a mailing list telling developers to not plan on being able to create alternate clients. Poor timing? Possibly. They very well could have been planning this announcement for some time. Still seems odd.

But what if they had challenged themselves internally? “We are going to make such a kick ass experience for the desktop, mobile and web, users won’t bother with these imitators.” They could have looked at who was doing great things with the iPhone and the desktop and simply hired them to make their product better. Listened to their users to see what features these other clients were offering and make them better. Isn’t that what free-market competition should be all about? Not, “hey, thanks for helping build up our user base, now go screw yourselves.”

Ultimately, Twitter really reminded me that I don’t pay for it, so I can’t really bitch about it, and should remember my goal of Less Twitter, more me..