Subscribe: Snook.ca
http://www.snook.ca/jonathan/index.rdf
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
approach  based approach  based  beacon  beacons  build  component  components  css  i’ve  people  physical web  remote  web  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Snook.ca

Snook.ca



Tips, Tricks and Bookmarks on Web Development.



 



How do I learn?

Thu, 22 Sep 2016 20:37:47 +0000

I hear this question quite a bit lately. Our industry feels like it’s expanding exponentially with new techniques and technologies. People feel overwhelmed and unsure how to ingest it all.

I’ve found that I have 3 phases to my learning process:

  1. Reading
  2. Building
  3. Writing

Reading — Superficial Learning

I read a lot. I’ll click on links from Hacker News, Facebook, and Twitter. I’ll read about new techniques and new technologies and integrate those learnings into what I already know.

This is very superficial. With this knowledge, I can refer back to things if somebody asks about how to solve a particular problem. I couldn’t necessarily apply the approach myself yet but I have enough to know that a solution exists. That in itself can be quite useful.

Building — Application and Expansion

From there, when I want to learn more about a given thing, I build something with it. Most recently, I wanted to learn about web beacons and took the time to make a beacon to see how it worked. I do this frequently. I’ll build small one-page apps to test out a concept. The exercise may take me anywhere from an hour to a week to build.

Building something expands my knowledge on a topic and now I can speak more authoritatively on the pros and cons of why and when you’d want to use such a technique or technology.

Writing — Explore the Edges

The last step is to write about it. This could be a blog post, a book, or a conference talk. When I write about a topic, I explore the edges of what I know, the edges outside of what I needed to initially implement the idea.

For example, it’s one thing to know that web beacons exist. It’s another thing to know how to implement them. It’s another thing to know the range and other limitations that exist.

In writing a blog post about all:initial, I forced myself to test in every browser and discovered how inconsistent the implementation was.

Reading, Building, Writing, Repeat

It’s not necessary to go through this process for everything. You can stay at the superficial level for many things and only dive deeper when you need to, like implementing an idea on a client project.

Likewise, you don’t need to write about everything you work on. Writing is, for me, how I learn a topic more intimately. Not everything needs to be learned that deeply.

As your career develops, you’ll gain a sense of what things to explore sooner rather than later, or not to explore at all.

I have a list of things I’d like to explore—like progressive web apps, service workers, and web components—and when I do, I’ll go through this same process again and again.




Physical Web Beacons

Thu, 15 Sep 2016 14:46:00 +0000

After hearing about the Physical Web through a second-hand tweet, I decided to look into what it is and why we want it. The Physical Web is essentially a way to broadcast a URL using Bluetooth (Bluetooth Low Energy or BLE, specifically). Devices can then listen for those beacons. The beacons can broadcast to a distance from a few centimetres away to possible 450 metres away. The Physical Web uses Eddystone, an open source beacon specification that Google proposed and is a competitor to Apple’s proprietary iBeacon technology. Google released Eddystone in July 2015. What’s the Frequency, Kenneth My initial reaction was “cool!” The practical applications of this could be quite numerous. For example, the web site shows a dog tag or a parking meter broadcasting. Stores could feature sales as you walk into them and have those broadcast directly to your phone. In Uri† Shaked’s overview of the Physical Web, he talks about being able to broadcast conference slides while doing a talk. Conferences could broadcast the day’s schedule. I could imagine going by a restaurant and being able to load up their menu via a beacon. Bus stops could broadcast maps and times. The QR Code of the Future Sadly, my mind quickly devolved into the annoyance of numerous notifications, like popup windows and other distracting adverts, vying for my attention. Imagine that same conference with companies pitching their wares or recruiters filling up your notifications. There could quickly be so many notifications as to make them near useless. Walking into a store, your phone buzzing with dozens of product sales, as companies pay for beacons and shelf space. The people behind the implementation of beacons at Google have worked hard to make sure they're not annoying. On Android, all beacons are wrapped up into a single silent notification. Essentially, you have to seek out beacons rather than have beacons nag you. Ultimately, though, beacons feel like QR codes. They’ll be all over the place and, for the most part, ignored. Priorities With the possible onslaught of beacons, some type of filtering or prioritization would seem ideal. Otherwise, I think most people would just rather choose to have beacons turns off, which wouldn’t really be of much use to those who use beacons. (Uri recognizes this issue in the comments of his article.) Trying them out Uri’s article does a great job of describing how to set up Beacons on your laptop or Raspberry Pi, and how to configure your iOS or Android devices to listen for them. Broadcasting a Beacon using Node On my Mac, I was able to broadcast a beacon with a couple easy lines: npm install --save eddystone-beacon node -e "require('eddystone-beacon').advertiseUrl('https://snook.ca/');" Of note, URLs need to be https. I tried specifying an http URL as a beacon and it couldn’t be found. I tried specifying an http URL that redirects to https and it could be found. I’m not sure if it’s the sender or the receiver that’s doing the double-check on the URL. (Also, you might have to use sudo to get npm to install everything correctly.) Listening to Beacons On iOS, add Chrome to the Today screen. You’ll be prompted to listen to Physical Web beacons. Don’t worry, you can disable it later. On Android, notifications will come up automatically. Da Bears I’m still bearish on beacons but I like the potential. I may try setting up beacons at upcoming conferences and workshops to see how well it works. † How cool is it to have a name like URI (Uniform Resource Identifier)?! Updated to point out that beacon notifications are silent.[...]



Working Remotely

Wed, 03 Aug 2016 18:25:07 +0000

I’ve been fortunate over the past decade to have been able to, in various capacities, work from home—or work in place, as some like to call it. First as a freelancer, then Yahoo!, then again when I went to work at Xero, and now back to working for myself. Shopify has been the exception to the rule in that time and while I tried to instill a culture of remote work, I don’t think I managed to move the needle much within the organization. So, after all that time, what have I seen that works and doesn’t work? If I were to start my own company, would I allow remote workers? If I were to join another company, how would I foster an environment that encouraged remote work? What works With the hindsight that comes from experience, what made it work? For me, it was about being given a discrete task with few or no dependencies. That’s it in a nutshell. When I was a freelancer, I worked with clients to determine the scope of work, was given the autonomy to do the work, and then delivered the work. At Yahoo!, especially in the beginning, I had a defined role that didn’t require much communication with the team or teams at large. I would get design work and then build out the front-end based on those. Again, being given the autonomy and trust to build things as I felt they should be built meant that I had very few dependencies. There was very little that would slow down my ability to produce work. (Well, except dealing with my own distractions—something that has become more difficult of late.) It was fun to hop into a conference call from South Africa. Or to have a co-worker contact me from the passenger seat of a car driving the coast of Italy. I’ve done conference talks from hotel rooms. I’ve done work meetings from coffee shops around the world. What didn’t work Not everything was peachy, though. At Yahoo!, I was placed into a managerial role. Managing a team remotely, for example, didn’t go so well. I needed to be in lots of meetings and if people didn’t log into the teleconference, I was left out of the loop. I didn’t really know how to manage a team and that training was never provided, nor was it requested. In the early days of my time at Shopify, I tried to convince management that supporting remote workers would make us a better company. But I didn’t know how to go about making remote work for the company. As a result, the initiatives that were implemented just fizzled. Instead, each remote office was given tasks that allowed them to work more autonomously. At Xero, my struggle was mostly in dealing with time zones. Living in a time zone 8 hours away meant that meetings often fell in the evenings when I had family commitments. As a result, I missed countless meetings. While my team never made mention of it, I felt increasingly out of the loop and ineffectual. Would I Lead a Remote Team? Given my experience, would I build and lead a remote team? Yes. Now that I have some experience behind me, I think I could make it work. To do so, here are some things I would do: Have discrete tasks Give people ownership over something and give them the autonomy to build that thing with little initial oversight. There are opportunities through code reviews, design reviews, and other exercises to ensure that people are on the right track. Otherwise, get out of their way. Communicate in the open When you have some people in an office and some people out of the office, it’s easy for some communication to be isolated. The team in the office might come to a conclusion and never communicate it outside of the room that decision was made. For distributed teams, that’s awful. Communicate in the open. Every decision is documented. Find a place, be it Slack, GitHub, Trello, or wherever, and get the word out. Fostering Remote in a Company Considering my failures at Shopify, I’ve wondered how, if going into a new company, I could enable remote work. I think I would take a more grassroots approach. I’d implement it for my own team and [...]



How Will Web Components Change CSS Architecture?

Mon, 11 Jul 2016 16:26:00 +0000

With the slow rise of Web Components—the breakdown of interfaces into self-contained chunks of HTML, JavaScript, and CSS—will we see an evolution (or revolution) in how we manage the way we write, build, and bundle the CSS for our web sites? Currently there are two main approaches to writing CSS: component-based and utility-based. (I’ve also seen this referred to object and functional CSS, respectively.) Component-based A component-based approach establishes a 1-to–1 relationship between the HTML and the selectors. It does so by codifying a design pattern and applying it to an HTML element. For example, a button is codified in the CSS with a .button class and applied to an element. Since there’s a selector for every design pattern, as the number of design patterns on your site grows, so does the size of your CSS. Theoretically, there’s a cap to the number of design patterns you will or should have on your site. However, evolving designs and growing sites often continue to add to the codebase without removing old designs. I’ve seen sites with ten years worth of CSS that continued to be cobbled together. SMACSS falls squarely in this camp. Utility-based At the other end of the spectrum is a utility-based approach. It establishes a 1-to–1 relationship between the selectors and the CSS properties. For example, a button—consisting of a collection of CSS properties—receives a number of classes to style the HTML. There are only so many CSS properties and only so many values we set with those properties. As a result, the size of the CSS reaches a cap. Atomic CSS falls squarely in this camp. In the Middle Of course, there are people (er, most people, probably) that choose to blend these two styles together. Some use a component-based approach for some things, like buttons and inputs, and then use a utility-based approach for other things, like layout and spacing. Delivery How that CSS actually gets delivered to a user is a factor in all this. Most projects I’ve seen go all in. All of the CSS for a project is bundled together into a single file, minimized, then cached. When I was working at Yahoo!, the reason for the component-based approach was to be able to bundle only the CSS needed for the page and no more. Only when new pages with new components were loaded was the CSS for those components loaded. This was done through a “combo handler” that could combine the individual CSS files together at request time and cached. Web Components If you’ve looked into Web Components, that last bit should feel really familiar. If a Web Component is only requested when it’s used then the embedded CSS will only be used when the Web Component is requested. Web Components actually consist of 4 different technologies: custom elements, HTML imports, Templates, and Shadow DOM. When I refer to Web Components in this article, I refer to them as a collective whole. An actual project not using HTML imports, for example, might use a different strategy for bundling and loading components into a project. A project could still bundle the whole app into one fell swoop like many people do today. In which case, none of what I’m talking about here really applies. That means that a component-based approach allows us to localize CSS to a given component and get the performance benefits of only using that CSS when it’s needed. Many in the React world using inline CSS are essentially doing the same thing. They’re writing CSS in the component and that CSS only gets used when the component is requested. As you can probably guess, my approach (with SMACSS, natch) to building a site using Web Components doesn’t really change. Some concerns like using naming convention to namespace CSS fall by the wayside due to the Shadow DOM. For those using a utility-based approach will still need to go through a bundling process but with the file size being (theoretically) reasonably sized, this isn’t really an issue. Each[...]