Anthony Panozzo's Blog

I was taking a look around the Mozilla Developer Network site to learn more about HTML elements. While doing so, I saw a few that I either didn't use or thought that I could be using more and wanted to share with you. For each, I'll post what it is and why you might consider using it more in your code.

Why would you do such a thing?

I think this is interesting because even while I do web development quite a bit, there are always new things coming out. While I might have been familiar with elements a few years ago, the built-in tags are evolving. (I tried to avoid tags in this post that were not supported by most browsers.)

This actually applies to many areas of learning and knowledge. What we think we know ends up being inaccurate or incomplete, so we need to continually review and reevaluate what we know.

The main recurring theme in this post is that more accurate tags allow us to capture the semantics of the content that we have in them. When we use semantic tags, we give a deeper understanding of what the content actually means. Search engines and other automated tools can get a better understanding of our website, and while we are working with it, we also can understand the intent more clearly.

With HTML5, we can create any tag we want. By seeing what tags are already there, we avoid reinventing tags. Also we can get ideas for semantic tags that we can create in our own projects.

Tag, You're It!

<address>

I like this tag because it is pretty common to put an address on a web page (maybe in the footer or on a contact/about page.) But instead of putting it in a <div> or something, this tag allows us to be semantic about the address.

<code>

This tag is more common. Again, using it is more semantic than using something like a <pre> tag for displaying monospaced text. It signifies that the contents are computer code.

I just finished up the Fluent Forever book by Gabriel Wyner and thought it was great. I'm interested in learning Spanish, and I like the approach that the book takes. It has solid advice and is backed up with some research citations.

In this post I'll break down my key takeaways from the book and the accompanying website which has rich videos. Check out Derek Sivers's post for an in-depth review.

Spaced repetition is key

Consistent spaced repetition underpins the entire system. I won't go into heavy detail in this post, but it is basically a way to create flash cards that you see at the optimal time for retention. An algorithm determines how often you will see cards, so you only review cards that you actually need to review. By setting up small cards that you can review, you can learn and retain a lot of information.

Wanted to share an organization system that I came up with that combines my weekly flip fold calendar idea and life gamification. In this post I'll give you a template to use to set up your own system. Wanted to share since I was thinking about systems like this recently and realized that I hadn't written it up yet.

Basically, you set up your daily goals, and they total to 100 points per day. Then, you have some weekly goals, and they should total to 300 points. Then at the end of the week, you see how many of your goals you have accomplished. 700 points would be a 70% success rate. I made it 1000 points just because it was a nice round number and I think it was a good weighting for daily and weekly items. You need to do daily habits (they can be simple), but also keep your weekly goals in mind.

In one of the Slack organizations I am in, some of the people in the design channel were talking about how spec work permeates their industry and how it is harmful. They talked about how this came to be and the effects of it. I stayed out of the discussion for a while, but I finally posted this to try to help understand what they were saying and state my perspective. Since I thought it might be valuable to you if you are a freelancer or consultant, wanted to share it here.

The Post

I have worked more in a software development capacity, so I am not steeped in the "spec work" culture as much, but I basically would not give work away for free for someone who is able to pay money. I think part of our responsibility as people who take on clients is to verify the following before engaging to learn more:

I am working on a couple of projects that use Ruby on the back end and JavaScript on the front end. The Ruby convention for variables is snake_case, while JavaScript variables are camelCased. This causes friction when we pass things between the front end and the back end.

An ad-hoc solution might result in the Ruby code handling some camel-cased variables when reading in JSON or when sending a response. Otherwise, the JavaScript code has underscores all over the place, which is also undesirable. It has the effect of cluttering up our front end code.

Overall, this discrepancy makes it harder to derive the right variable name each time on both the server and the client. Languages have conventions primarily to make it easier to remember what to call things. However, this breaks down when there are two or more languages in play that have different conventions.

A solution that I implemented that I'm pretty happy with so far is to consistently snake- and camel-case on the server. This can be done with two steps. First, we create a middleware that intercepts requests with a JSON body and converts the keys to snake-case. Then, whenever we send a JSON response, we convert the response to camel-case for the client to consume.