You are here

thinktime

Money for nothing

Seth Godin - Fri 27th Oct 2017 20:10
A friend asked me for some ways to make money. (All direct quotes). "Can I do okay taking those surveys where they pay me?" "What about buying or trading shirts from Supreme and then selling them?" "Do you think I...        Seth Godin
Categories: thinktime

OpenSTEM: Happy Teachers’ Day

Planet Linux Australia - Fri 27th Oct 2017 15:10
OpenSTEM would like to extend warm congratulations to all teachers on Teachers’ Day!! We salute you all for the wonderful job you do for all students every day, often without thanks or praise. It is not lightly that people say “If you can read this, thank a teacher”. Teachers truly are the force that shapes […]
Categories: thinktime

OpenSTEM: This Week in HASS – term 4, week 4

Planet Linux Australia - Fri 27th Oct 2017 11:10
This week our youngest students are looking at Aboriginal Places, while slightly older students are comparing Australia to other places around the world. Our older students are starting their class election segment of work, covering several parts of the Civics and Citizenship, as well as the History, curricula. Foundation/Kindy/Prep to Year 3 Students in Foundation/Kindy/Prep […]
Categories: thinktime

Coding with Clarity

a list apart - Thu 26th Oct 2017 23:10

Working code isn’t necessarily good code. Your code also needs to be easy to read, understand, and modify. It needs clarity, and to achieve that, it has to be organized well, with careful planning and proper separation of ideas taking place before you even open your code editor. Coding for clarity is something that separates the great developers from the merely good, and there are a few basic principles that can set you on that path.

Note: Though the principles in this article are applicable to a variety of programming languages, most of the examples pull from object-oriented JavaScript. If you’re not familiar with this, A List Apart has articles on the module pattern and prototypal inheritance to help bring you up to speed.

The single responsibility principle

Imagine you’re working on a home project and you pick up a drill to drive a screw into a wall. When you pull the drill away from the screw, you discover that this drill has an interesting feature: it squirts a quick-drying drywall compound over the driven screw to hide it. Well, that’s great if you want to paint over the screw, but that’s not always the case. You shouldn’t have to get a second drill just to drill a hole in something. The drill would be much more usable and reliable if it just did one thing, and it would also be flexible enough to use in a variety of situations.

The single responsibility principle states that a block of code should do one thing, and do it well. Like the drill above, limiting its functionality actually increases the usefulness of a block of code. Coding this way not only saves you a lot of headache, but it will save future developers on the project a lot of headache as well.

Think of functions and methods in terms of responsibilities. As you increase its responsibilities, a block of code becomes less flexible and reliable, more demanding of changes, and more susceptible to errors. For the most clarity, each function or method should have one responsibility.

If you’re describing what a function does and you have to use the word “and,” that function is probably too complex. What a function does should be simple enough to explain with only a descriptive function name and descriptive arguments.

I was tasked recently with creating an electronic version of the Myers-Briggs personality test. I’d done this before, and when I first approached the problem a few years ago, I coded one giant function called processForm—it gathered the scores, generated the charts, and took care of everything in the DOM to display things to the user.

The problem was that if anything had to change, you had to search through a mountain of code to figure out where to make the alteration. Also, if something went wrong in the middle of the function, it was a lot harder to find the error.

So when facing the problem this time, I broke everything down into single-responsibility functions wrapped up in a module object instead. The resulting function called upon form submission looked like this:

return { processForm: function() { getScores(); calculatePercentages(); createCharts(); showResults(); } };

(View complete app here)

Extremely easy to read, understand, and modify—even a non-coder can make sense of this. And each of those functions does (you guessed it!) only one thing. This is the single responsibility principle in action.

If I wanted to add form validation, rather than having to modify a giant working function (potentially breaking it), I could simply add a new method. This approach also enables related logic and variables to be segmented off, cutting down on conflicts for greater reliability, and it makes it very easy to reuse the function for other purposes if needed.

So remember: one function, one responsibility. Large functions are where classes go to hide. If a function does lots of things that are closely tied together and that are working with the same data, it would make more sense to break it up into an object with methods, much like I did with my large form function.

Command-query separation

The funniest email chain I’ve ever seen was the series of Missing Missy posters from David Thorne about a missing cat. Each time his coworker Shannon makes a request, David complies, but puts his own little twist on it and delivers something different than what was expected. The exchange is very funny and worth a read, but it’s less funny when your code does the same thing.

Command-query separation provides a basis of safeguarding your code against unintended side effects to avoid surprises when functions are called. Functions fall into one of two categories: commands, which perform an action, and queries, which answer a question. You should not mix them. Consider the following function:

function getFirstName() { var firstName = document.querySelector("#firstName").value; firstName = firstName.toLowerCase(); setCookie("firstName", firstName); if (firstName === null) { return ""; } return firstName; } var activeFirstName = getFirstName();

This is a simplistic example—most side effects are harder to find—but you can see some potentially unanticipated side effects in action.

The function name, getFirstName, tells us that the function is going to return the first name. But the first thing it does is convert the name to lowercase. The name says it’s getting something (a query), but it’s also changing the state of the data (a command)—a side effect that is not clear from the function name.

Worse, the function then sets a cookie for the first name without telling us, potentially overwriting something we could have been counting on. A query function should never, ever overwrite data.

A good rule of thumb is that if your function answers a question, it should return a value and not alter the state of the data. Conversely, if your function does something, it should alter the state of the data and not return a value. For maximum clarity, a function should never return a value and alter the state of the data.

A better version of the code above would be:

function getFirstName() { var firstName = document.querySelector("#firstName").value; if (firstName === null) { return ""; } return firstName; } setCookie("firstName", getFirstName().toLowerCase());

This is a basic example, but hopefully you can see how this separation can clarify intent and prevent errors. As functions and code bases become larger, separation becomes much more important, as hunting for the function definition whenever you want to use it just to find out what it does is not an efficient use of anybody’s time.

Loose coupling

Consider the difference between a jigsaw puzzle and Lego blocks. With a jigsaw puzzle, there’s only one way to put the pieces together, and there’s only one finished product. With Lego, you can put the pieces together any way you want to make any end result you want. If you had to pick one of these types of building block to work with before you knew what you’d be building, which would you choose?

Coupling is a measure of how much one program unit relies on others. Too much coupling (or tight coupling) is rigid and should be avoided. That’s the jigsaw puzzle. We want our code to be flexible, like Lego blocks. That’s loose coupling, and it generally results in much greater clarity.

Remember, code should be flexible enough to cover a wide variety of use cases. If you find yourself copying and pasting code and making minor changes, or rewriting code because code changed somewhere else, this is tight coupling in action. (For example, to make the getFirstName function from earlier reusable, you could replace the hard-coded firstName with a generic ID passed to the function.) Other signs of this include hard-coded IDs in functions, too many function parameters, multiple similar functions, and large functions that violate the single responsibility principle.

Tight coupling is most prevalent in a group of functions and variables that really should be a class instead, but it can also happen when classes depend on methods or properties from other classes. If you’re having trouble with interdependencies in functions, it’s probably time to think about breaking your functions into a class.

I encountered this when looking at some code for a series of interactive dials. The dials had a number of variables, including dimensions, handle size, fulcrum size, and more. Because of this, the developer was forced to either use an absurd amount of function parameters or create multiple copies of each function with the variables hard-coded in each one. Additionally, each dial did something different when interacted with. This led to three sets of nearly identical functions—one for each dial. In short, coupling was increased due to the hard-coding of variables and behavior, so, like a jigsaw puzzle, there was only one way to put those pieces together. The codebase was unnecessarily complex.

We solved the problem by breaking up the functions and variables into a reusable class that was instantiated for each of the three dials. We set up the class to take a function as an argument for output, so different outcomes could be configured when the individual dial objects were instantiated. As a result, we had fewer functions, and the variables were stored in only one place, making updates much easier.

Classes that interact with each other can also be culprits of tight coupling. Let’s say we have a class that can create objects of another class, like a college course that can create students. Our CollegeCourse class works fine. But then we need to add a parameter to the constructor of the Student class. Oh no! Now we have to modify our CollegeCourse class to account for the change in the Student class.

var CollegeCourse = (function() { function createStudent_WRONG(firstName, lastName, studentID) { /* If the Student constructor changes, we'll have to modify this method and all calls to it, too! */ } function createStudent_RIGHT(optionsObject) { /* Passing an object as an argument allows the Student object to deal with the change. We may need to change this method, but we won’t need to change any existing calls to it. */ } }());

You shouldn’t have to modify a class because another class changes. This is a classic case of tight coupling. Constructor parameters can be passed as an object with the receiving object having fallback default values, which loosens coupling and means code won’t break when you add new parameters.

The point is that you should build your code like Lego blocks, not like jigsaw puzzle pieces. If you find yourself facing problems similar to the ones above, the problem is probably tight coupling.

High cohesion

Have you ever seen a kid clean a room by stuffing everything into the closet? Sure, it works, but it’s impossible to find anything and things that don’t belong together often get placed right next to each other. The same can happen with our code if we don’t strive for a high level of cohesion.

Cohesion is a measure of how much the various different program units belong together. A high level of cohesion is good and adds clarity to code blocks; a low level of cohesion is bad and leads to much confusion. Functions and methods in a code block should make sense together—they’ll have a high level of cohesion.

High cohesion means sticking related things, like database functions or functions relating to a particular element, in one block or module. This helps not only with understanding how such things are laid out and where to find them, but also with preventing naming conflicts. If you have 30 functions, the chances of a conflicting name are far greater than if you have 30 methods split over four classes.

If two or three functions use the same variables, they belong together; this is a great case for an object. If you have a series of functions and variables that control a page element, like a slider, it’s a great opportunity for high cohesion, so you should bundle them up into an object.

Remember the example above about the class we made that decoupled the solution for the dial? That’s a great case of high cohesion as a cure for tight coupling. In that case, high cohesion and tight coupling were on opposite ends of a sliding scale, and focusing on one fixed the other.

Repeated code is a sure sign of low cohesion. Similar lines of code should be broken into functions, and similar functions should be broken into classes. The rule of thumb here is that a line of code should never be repeated twice. In practice, this isn’t always possible, but for clarity’s sake you should always be thinking about how to cut down on repetition.

Similarly, the same bit of data should not exist in more than one variable. If you’re defining the same bit of data in multiple places, you definitely need a class. Or if you find yourself passing references to the same HTML element to multiple functions, the reference should probably be a property in an instance of a class.

Objects can even be put inside other objects to increase cohesion further. For example, you might put all AJAX functions in a single module that includes objects for form submission, grabbing content, and login syntax, like so:

Ajax.Form.submitForm(); Ajax.Content.getContent(7); Ajax.Login.validateUser(username, password);

Conversely, you shouldn’t throw unrelated things together in the same class. An agency I used to work for had an internal API with an object called Common that had a hodgepodge of common methods and variables that had nothing to do with each other. The class became huge and confusing simply because there was little thought given to cohesion.

If properties are not used by multiple methods in a class, this can be a sign of low or bad cohesion. Similarly, if methods can’t be reused in a few different situations—or if a method isn’t used at all—this can also be a sign of low or bad cohesion.

High cohesion helps to alleviate tight coupling, and tight coupling is a sign that greater cohesion is needed. If the two ever come into conflict, though, choose cohesion. High cohesion is generally a greater help to the developer than loose coupling, although both can usually be accomplished together.

Conclusion

If our code is not immediately clear, problems occur. Achieving clarity is about so much more than proper indentation—it takes careful planning from the beginning of the project. While tough to master, abiding by the principles of single responsibility, command-query separation, loose coupling, and high cohesion can improve clarity in our code greatly. It should be a consideration in any significant programming project.

Categories: thinktime

Russell Coker: Anarchy in the Office

Planet Linux Australia - Thu 26th Oct 2017 23:10

Some of the best examples I’ve seen of anarchy working have been in corporate environments. This doesn’t mean that they were perfect or even as good as a theoretical system in which a competent manager controlled everything, but they often worked reasonably well.

In a well functioning team members will encourage others to do their share of the work in the absence of management. So when the manager disappears (doesn’t visit the team more than once a week and doesn’t ask for any meaningful feedback on how things are going) things can still work out. When someone who is capable of doing work isn’t working then other people will suggest that they do their share. If resources for work (such as a sufficiently configured PC for IT work) aren’t available then they can be found (abandoned PCs get stripped and the parts used to upgrade the PCs that need it most).

There was one time where a helpdesk worker who was about to be laid off was assigned to the same office as me (apparently making all the people in his group redundant took some time). So I started teaching him sysadmin skills, assigned work to him, and then recommended that my manager get him transferred to my group. That worked well for everyone.

One difficult case is employees who get in the way of work being done, those who are so incompetent that they break enough things to give negative productivity. One time when I was working in Amsterdam I had two colleagues like that, it turned out that the company had no problem with employees viewing porn at work so no-one asked them to stop looking at porn. Having them paid to look at porn 40 hours a week was much better than having them try to do work. With anarchy there’s little option to get rid of bad people, so just having them hang out and do no work was the only option. I’m not advocating porn at work (it makes for a hostile work environment), but managers at that company did worse things.

One company I worked for appeared (from the non-management perspective) to have a management culture of doing no work. During my time there I did two “annual reviews” in two weeks, and the second was delayed by over 6 months. The manager in question only did the reviews at that time because he was told he couldn’t be promoted until he got the backlog of reviews done, so apparently being more than a year behind in annual reviews was no obstacle to being selected for promotion. On one occasion I raised the issue of a colleague who had done no work for over a year (and didn’t even have a PC to do work) with that manager, his response was “what do you expect me to do”! I expected him to do anything other than blow me off when I reported such a serious problem! But in spite of that strictly work-optional culture enough work was done and the company was a leader in it’s field.

There has been a lot of research into the supposed benefits of bonuses etc which usually turn out to reduce productivity. Such research is generally ignored presumably because the people who are paid the most are the ones who get to decide whether financial incentives should be offered so they choose the compensation model for the company that benefits themselves. But the fact that teams can be reasonably productive when some people are paid to do nothing and most people have their work allocated by group consensus rather than management plan seems to be a better argument against the typical corporate management.

I think it would be interesting to try to run a company with an explicit anarchic management and see how it compares to the accidental anarchy that so many companies have. The idea would be to have minimal management that just does the basic HR tasks (preventing situations of bullying etc), a flat pay rate for everyone (no bonuses, pay rises, etc) and have workers decide how to spend money for training, facilities, etc. Instead of having middle managers you would have representatives elected from each team to represent their group to senior management.

PS Australia has some of the strictest libel laws in the world. Comments that identify companies or people are likely to be edited or deleted.

Related posts:

  1. Preferring Not To I’ve just read Bartleby the Scrivener which is a short...
  2. Contract Pay Rates In a comment on my post about Bad Project Management...
  3. more about securing an office My post about securing an office received many comments, so...
Categories: thinktime

Important, popular or viral

Seth Godin - Thu 26th Oct 2017 20:10
Important work is easily dismissed by the audience. It involves change and risk and thought. Popular work resonates with the people who already like what you do. Viral work is what happens when the audience can't stop talking about what...        Seth Godin
Categories: thinktime

Reverso g-h-o-s-t (off topic)

Seth Godin - Wed 25th Oct 2017 19:10
This is my favorite game. It doesn't involve a board, there are no cards and it's free to play. It works for two to six players. You can do it in a car or a plane, it works great for...        Seth Godin
Categories: thinktime

Lev Lafayette: Teaching High Throughput Computing: An International Comparison of Andragogical Techniques

Planet Linux Australia - Wed 25th Oct 2017 15:10

The importance of High Throughput Computing (HTC), whether through high performance or cloud-enabled, is a critical issue for research institutions as data metrics are increasing at a rate greater than the capacity of user systems [1]. As a result nascent evidence suggests higher research output from institutions that provide access to HTC facilities. However the necessary skills to operate HTC systems is lacking from the very research communities that would benefit from them.

read more

Categories: thinktime

Lev Lafayette: Spartan and NEMO: Two HPC-Cloud Hybrid Implementations

Planet Linux Australia - Wed 25th Oct 2017 15:10

High Performance Computing systems offer excellent metrics for speed and efficiency when using bare metal hardware, a high speed interconnect, and parallel applications. This however does not represent a significant portion of scientific computational tasks. In contrast cloud computing has provided management and implementation flexibility at a cost of performance. We therefore suggest two approaches to make HPC resources available in a dynamically reconfigurable hybrid HPC/Cloud architecture. Both can can be achieved with few modifications to existing HPC/Cloud environments.

read more

Categories: thinktime

The New CSS Layout, An Excerpt

a list apart - Wed 25th Oct 2017 01:10

A note from the editors: We’re pleased to share an excerpt from Chapter 3 (“The New Layout”) of Rachel Andrew’s new book, The New CSS Layout, available now from A Book Apart.

As we have seen, flexbox wasn’t designed for grid layouts—but this is where our newest specification is most at home. CSS Grid Layout does exactly what its name suggests: it enables the creation of grid layouts in CSS. This is two-dimensional layout—laying things out as a row and a column at the same time. We’ll go over many more examples of Grid Layout in the rest of this book, but let’s start by seeing how Grid can solve the problem we had with making flexbox display like a grid.

In this example, I’m creating a three-column grid (Fig 3.17). My container has display: grid, and I’ve created three equal-width columns with the grid-template-columns property, plus a new unit created for Grid: a flexible-length unit known as fr. We’ll take a closer look at this unit in Chapter 5; for now, keep in mind that it represents a fraction of the space available in the grid container. With three tracks all set to 1fr each, the available space is divided into three and distributed equally. This is all we need to do to get the direct child of the container to display as a grid. Unlike with flexbox, we don’t need to add any rules to the children; they will just pop themselves into each cell of the grid.

.cards { margin: 0 -10px; display: grid; grid-template-columns: 1fr 1fr 1fr; }

Code example: http://bkaprt.com/ncl/03-14/

   

Fig 3.17: The basic grid layout.

As you can see, the items form a strict grid, without us needing to set any widths on them. We can solve another issue that we have with creating a flexbox grid, using properties that are part of the Grid specification. To create gaps between our flex items, in our flexbox example we used margins on the flex items and then needed to add a negative margin on the container to account for the unwanted left and right margin on the far left and right items. CSS Grid Layout includes a grid-gap property to space items out. This property is shorthand for grid-column-gap and grid-row-gap, which can also be specified individually.

To demonstrate how this works, I’ve removed the margins on the items and the negative margin on the container and spaced the items out with grid-gap. You’ll produce the exact same layout as above in the browser, but without the need to mess around with margins and negative margins.

.cards { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-gap: 20px; }

Code example: http://bkaprt.com/ncl/03-15/

Just as this book was going to print, the CSS Working Group resolved to change the name of the grid-gap properties. grid-column-gap will become column-gap, grid-row-gap will become row-gap, and the grid-gap shorthand will simply be gap. In addition, the definition of these properties has been moved to the Box Alignment Specification. This means that in the future, flexbox may also support gaps in the same way as Grid.

Because browsers have already shipped these properties, they will alias the grid-* names to the new names for the foreseeable future. At time of writing, no browser supports the new property names, so I’ve retained the grid-* versions in these examples. If you want to be sure of supporting both versions, there’s no reason not to list both in your CSS, as in this example:

.cards { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-gap: 20px; gap: 20px; } Positioning items around the grid

We can quickly move away from what flexbox allows us to do by taking advantage of our two-dimensional grid and positioning items on it. The most basic way of doing this is by using line numbers. A grid has numbered grid lines; they start from 1 for both rows and columns. Note that these lines are numbered per the writing mode of the document. Working in English, a left-to-right (LTR) language, column line 1 is on the left-hand side of the grid; row line 1 is at the top. In Arabic, a right-to-left (RTL) language, column line 1 appears on the right of the grid. The far edge of the grid (right in a LTR language and left in a RTL language) is represented by -1.

.cards { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-gap: 20px; } .card1 { grid-column: 1 / 3; grid-row: 1; } .card2 { grid-column: 3; grid-row: 1; } .card3 { grid-column: 1; grid-row: 2 / 4; } .card4 { grid-column: 2 / 4; grid-row: 2; } .card5 { grid-column: 2 / 4; grid-row: 3; }

Code example: http://bkaprt.com/ncl/03-16/

   

Fig 3.18: Cards placed on the grid by line number.

You can immediately see some of the power of Grid Layout here. We can span columns and rows—something that is hard to do using existing layout methods. The background color of our cards extends to the gutter, even if the content is shorter. It’s also very easy to change how far a block spans—we can even leave white space! If I change the start line of card 3 to row line 3, we get an empty cell (Fig 3.19). Nothing can rise and land in the grid cell; this differs from the behavior of floats, which try to float up and fill the available space.

   

Fig 3.19: White space made easy with CSS Grid Layout.

Another method of positioning items on a grid involves using named areas. This allows you to describe your layout right in your CSS. To do this with our example, we first give each card a name with the grid-area property. I’m just using letters a through e.

.card1 { grid-area: a; } .card2 { grid-area: b; } .card3 { grid-area: c; } .card4 { grid-area: d; } .card5 { grid-area: e; }

Next, I add the grid-template-areas property to the container. The value of this property describes what our layout should look like (Fig 3.20).

.cards { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-gap: 20px; grid-template-areas: "a a b" "c d d" "c e e"; }

Code example: http://bkaprt.com/ncl/03-17/

   

Fig 3.20: The value of grid-template-areas shows visually what our layout looks like.

There are a few things to keep in mind with grid-template-areas. To span across cells, we repeat the name of the area. Card 1 spans across the first two column tracks; thus a is repeated. The areas must be rectangular in nature—we can’t yet create an L-shaped area.

To leave white space, and to leave a cell empty, use a full-stop character. If you replace the first c with ., that cell will remain empty when the layout is created (Fig 3.21).

.cards { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-gap: 20px; grid-template-areas: "a a b" ". d d" "c e e"; }    

Fig 3.21: We now have white space left in our layout.

If your grid-area names are longer than one character, you may want to line up the visual rows and columns in the value of grid-template-areas. This is possible because more than one full-stop character can denote an empty cell—if they have no white space between them. You can also add more than one white-space character to space out grid-area names.

This is a very nice way to work with layouts, given how easy it is to move items around. I enjoy working like this during the prototyping stage—rather than worrying about how to achieve layout, I can figure out the best way for my interface to be presented. Then I can go back to the markup to make sure it’s in a logical order based on those decisions.

With these few examples, you already have enough knowledge to start using Grid Layout, and to make decisions about which layout methods to use. There is more to come, but keep in mind that although the specification is large and can do a lot of things, it is very simple at its core. You can do a lot with very little CSS. As you start building layouts, you will have questions, and will want to achieve more with these layout methods. That’s where the rest of this book comes in!

 

Categories: thinktime

Degrees of freedom

Seth Godin - Tue 24th Oct 2017 18:10
All you have to do is look around to realize just how many choices we still have. What to eat, who to speak to, what to do for a living, what to learn, what to say, who to contribute to,...        Seth Godin
Categories: thinktime

Date certain

Seth Godin - Mon 23rd Oct 2017 19:10
Some work is best shipped when it's done. Most of the time, though, we produce useful, important work on time. When it's due. If you're having trouble shipping, it might because you've hesitated to put a date on it. "Soon"...        Seth Godin
Categories: thinktime

Stuntvertising

Seth Godin - Sun 22nd Oct 2017 18:10
The math has changed. It used to be, you paid money to run an ad. A little piece of media, bought and paid for. The audience came with the slot. Today, of course, the ad is free to run. Post...        Seth Godin
Categories: thinktime

Decision making, after the fact

Seth Godin - Sat 21st Oct 2017 19:10
Critics are eager to pick apart complex decisions made by others. Prime Ministers, CEOs, even football coaches are apparently serially incompetent. If they had only listened to folks who knew precisely what they should have done, they would have been...        Seth Godin
Categories: thinktime

What will you do with your surplus?

Seth Godin - Fri 20th Oct 2017 18:10
If you have a safe place to sleep, reasonable health and food in the fridge, you're probably living with surplus. You have enough breathing room to devote an hour to watching TV, or having an argument you don't need to...        Seth Godin
Categories: thinktime

James Morris: Security Session at the 2017 Kernel Summit

Planet Linux Australia - Fri 20th Oct 2017 13:10

For folks attending Open Source Summit Europe next week in Prague, note that there is a security session planned as part of the co-located Kernel Summit technical track.

This year, the Kernel Summit is divided into two components:

  1. An invitation-only maintainer summit of 30 people total, and;
  2. An open kernel summit technical track which is open to all attendees of OSS Europe.

The security session is part of the latter.  The preliminary agenda for the kernel summit technical track was announced by Ted Ts’o here:

There is also a preliminary agenda for the security session, here:

Currently, the agenda includes an update from Kees Cook on the Kernel Self Protection Project, and an update from Jarkko Sakkinen on TPM support.  I’ll provide a summary of the recent Linux Security Summit, depending on available time, perhaps focusing on security namespacing issues.

This agenda is subject to change and if you have any topics to propose, please send an email to the ksummit-discuss list.

 

Categories: thinktime

OpenSTEM: This Week in HASS – term 4, week 3

Planet Linux Australia - Fri 20th Oct 2017 11:10
This week our youngest students are looking at special places locally and around Australia, slightly older students are considering plants and animals around the world, while our older students are studying aspects of diversity in Australia. Foundation/Prep/Kindy to Year 3 Students in standalone Foundation/Prep/Kindy (Unit F.4) and combined classes with Year 1 (F-1.4) are thinking […]
Categories: thinktime

A publishing master class

Seth Godin - Fri 20th Oct 2017 02:10
Announcing a two-day workshop in my office for 8 people. I define publishing as the work of investing in intellectual property and monetizing it by bringing it to people who want to pay for it. The world of publishing is...        Seth Godin
Categories: thinktime

The Story of CSS Grid, from Its Creators

a list apart - Thu 19th Oct 2017 23:10

A note from the editors: We want to thank the Microsoft Edge team for sharing transcripts of the interviews they conducted with many of the brilliant people who have contributed to the development of CSS Grid. Those transcripts proved invaluable in compiling this history. You can watch the short video they produced from those interviews, Creating CSS Grid, on Channel 9.

On October 17th, Microsoft’s Edge browser shipped its implementation of CSS Grid. This is a milestone for a number of reasons. First, it means that all major browsers now support this incredible layout tool. Second, it means that all major browsers rolled out their implementations in a single year(!), a terrific example of standards success and cross-browser collaboration. But third, and perhaps most interestingly, it closes the loop on a process that has been more than 20 years in the making.

Not a new idea

While the modern concept of a “grid layout” has been with us since the Industrial Revolution, grids have been a design tool for centuries. As such, it shouldn’t come as a shock that grid-based layouts have been a goal of CSS since the beginning.

According to Dr. Bert Bos, who co-created CSS with Håkon Wium Lie, grid-based layouts have actually been on his mind for quite some time.

“CSS started as something very simple,” Bos recalled. “It was just a way to create a view of a document on a very simple small screen at the time. Twenty years ago, screens were very small. So, when we saw that we could make a style sheet for documents, we thought, Well, what else can we do now that we have a system for making style sheets?

Looking at what books and magazines were doing with layout was a great inspiration for them.

“Independent of the content on every page, it has a certain layout,” Bos said. “Page numbers are in certain places. And images are always aligned to the certain sides—left or right or in the middle. We wanted to capture that.”

Early on, browser makers wrote off the idea as “too complex” to implement, but grid layout concepts kept cropping up. In 1996, Bos, Lie, and Dave Raggett came up with a “frame-based” layout model. Then, in 2005, Bos released the Advanced Layout Module, which later turned into the Template Layout Module. Despite enthusiasm for these concepts from the web design community, none of them ever shipped in a browser.

Once more, with feeling

With grid concepts being thrown at the wall of the CSS Working Group with some regularity, folks were hopeful one of them would stick eventually. And the idea that did was a proposal from a couple of folks at Microsoft who had been looking for a more robust layout tool for one of their web-based products.

Phil Cupp had been put in charge of the UI team tasked with reimagining Microsoft Intune, a computer management utility. Cupp was a big fan of Silverlight, a browser plug-in that sported robust layout tools from Windows Presentation Foundation, and initially had planned to go that route for building the new Intune. As it happened, however, Microsoft was in the planning stages of Windows 8 and were going to enable building apps with web technologies. Upon learning this, Cupp wanted to follow suit with Intune, but he quickly realized that the web was in desperate need of better layout options.

He joined a new team so he could focus on bringing some of the rich layout options that existed in Silverlight—like grid layout—to the web. Interestingly, folks on this new team were already noticing the need. At the time, many app developers were focusing on iPhones and iPads, which only required designers to consider two different fixed canvas sizes (four, if you consider portrait and landscape). Windows had to support a ton of different screen sizes, screen resolutions, and form factors. Oh, and resizable windows. In short, Microsoft needed a robust and flexible layout tool for the web desperately if the web was going to be an option for native app development on Windows.

After working extensively with various teams within Microsoft to assemble a draft specification, Cupp and his team shipped a grid layout implementation behind the -ms- vendor prefix in Internet Explorer 10 in 2011. They followed that up with a draft Grid Layout spec, which they presented to the W3C in 2012.

Of course, this was not the first—or even the third—time the W3C had received a grid layout spec to consider. What was different this time, however, was that they also had an actual implementation to evaluate and critique. Also, we, as developers, finally had something we could noodle around with. Grid layout was no longer just a theoretical possibility.

A handful of forward-thinking web designers and developers—Rachel Andrew, an Invited Expert to the W3C, chiefly among them—began to tinker.

“I came across CSS Grid initially at a workshop that Bert Bos was leading in French. And I don’t really speak French, but I was watching the slides and trying to follow along,” Andrew recalled. “I saw him demonstrate … the Template Layout spec. I think he was really talking about it in terms of print and using this stuff to create print layouts, but as soon as I saw that, I was like, No, we want this for the web. This is something that we really need and its feasibility to properly lay things out. And so I started digging into it, and finding out what he was doing, and building some examples.”

“Then I saw the Microsoft implementation [of the draft Grid Layout spec], which gave me a real implementation that I could build examples to show other people. And I wanted to do that—not just because it was interesting, and I like interesting things to play with—it was because I wanted to get it out there and get other people to have a look at it. Because I’ve been doing this for a long time and I know that specs often show up, and then no one really talks about them, and they kinda disappear again. And I was absolutely determined that Grid Layout wasn’t gonna disappear, it was gonna be something that other people found out about and got excited about it. And hopefully we’d actually get it into browsers and be able to use it.”

The spec evolves

The draft spec that Cupp presented to the W3C, and that his team shipped in IE10, is not the Grid Layout spec we have today. It was a step in the right direction, but it was far from perfect.

“The one [Phil Cupp submitted] was a very track-based system,” recalled Elika Etemad, an Invited Expert to the W3C and an Editor of the CSS Grid Layout Module. “There was only a numeric addressing system, there were no line names, there [were] no templates, none of that stuff. But it had a layout algorithm that they … were confident would work because they had been doing experimental implementations of it.”

“The original grid that Bert [Bos] came up with … was really the reason I joined the CSS Working Group,” recalled Google’s Tab Atkins, another Editor of the CSS Grid Layout Module. “At the time, I was learning all the terrible layout hacks and seeing the possibility to just write my page layout in CSS and just have it all, kinda, work was astonishing. And then seeing the draft from Phil Cupp … and seeing it all laid out properly and with a good algorithm behind it, I knew that it was something that could actually exist now.”

It was also a compelling option because, unlike previous proposals, which specified rigid layouts, this proposal was for a responsive grid system.

“You can [be] explicit about the size of a grid item,” Etemad explained. “But you can also say, Be the size that your content takes up. And that was what we needed to move forward.”

However, the draft spec wasn’t as approachable as many on the CSS Working Group wanted it to be. So the group looked to bring in ideas from some of its earlier explorations.

“What we really liked about Bert [Bos]’s proposal was that it had this very elegant interface to it that made it easy to express layouts in a way that you can intuitively see,” Etemad said. “It’s like an ASCII art format to create a template, and you could put [it] in your code, like the width of the columns and the heights of the rows. You could embed those into the same kind of like ASCII diagram, which made it a lot easier to see what you were doing.”

Peter Linss, then Co-Chair of the CSS Working Group, also suggested that they incorporate the concept of grid lines in the spec (instead of only talking about tracks). He believed including this familiar graphic design concept would make the spec more accessible to designers.

“When we were thinking initially about CSS Grid, we were thinking about it in a very app-centric model,” recalled Microsoft’s Rossen Atanassov, who is also an Editor on the spec. “But grid is nothing new. I mean, grid’s been here for a very long time. And that traditional type of grid has always been based on lines. And we’d been kind of ignoring the lines. When we realized that we could marry the two implementations—the app side and the typography side of the Grid—this for me, personally, was one of those aha moments that really inspired me to continue working on Grid.”

So the CSS Working Group began tweaking Microsoft’s proposal to incorporate these ideas. The final result allows you to think about Grid systems in terms of tracks or lines or templates or even all three at once.

Of course, getting there wasn’t easy.

Refine, repeat

As you can probably imagine, reconciling three different ideas—Microsoft’s proposal, Bos’ Advanced Layout, and Linss’ addition of grid lines—wasn’t a simple cut and paste; there were a lot of tricky aspects and edge cases that needed to be worked out.

“I think some of the tricky things at the beginning [were] taking all the different aspects of … the three proposals that we were trying to combine and coming up with a system that was coherent enough to gracefully accept all of that input,” Etemad said.

Some ideas just weren’t feasible for phase one of a CSS grid. Bos’ concept, for instance, allowed for any arbitrary descendent of the grid to lay out as though it were a child element of the grid. That is a feature often referred to as “subgrid” and it didn’t make the cut for CSS Grid Layout 1.0.

“Subgrid has been one of those things that was pointed out immediately,” Atanassov said. “And that has been a blessing and kind of a hurdle along the way. It was … one that held back the spec work for quite a bit. And it was also one that was scaring away some of the implementers. … But it’s also one of the features that I’m … most excited about going forward. And I know that we’re gonna solve it and it’s gonna be great. It’s just gonna take a little while longer.”

Similarly, there were two options for handling content mapped to grid lines. On the one hand, you could let the grid itself have fixed-dimension tracks and adjust which ending grid line the overflowing content mapped to, based on how much it overflowed. Alternately, you could let the track grow to contain the content so it ended at the predefined grid line. Having both was not an option as it could create a circular dependency, so the group decided to put the grid-snapping idea on hold.

Ultimately, many of these edits and punts were made in light of the CSS Working Group’s three primary goals for this spec. It needed to be:

  1. Powerful: They wanted CSS Grid to enable designers to express their desires in a way that “made simple things easy and complex things possible,” as Etemad put it;
  2. Robust: They wanted to ensure there would not be gaps that could cause your layout to fall apart, inhibit scrolling, or cause content to disappear accidentally;
  3. and Performant: If the algorithm wasn’t fast enough to elegantly handle real-world situations like browser resize events and dynamic content loading, they knew it would create a frustrating experience for end users.

“[T]his is why designing a new layout system for CSS takes a lot of time,” Etemad said. “It takes a lot of time, a lot of effort, and a lot of love from the people who are working on it.”

Where the rubber meets the road

Before a Candidate Recommendation (aka, a final draft) can become a Proposed Recommendation (what we colloquially refer to as a “standard”), the W3C needs to see at least two independent, interoperable implementations. Microsoft had implemented their draft proposal, but the spec had changed a lot since then. On top of that, they wanted to see other browsers take up the torch before they committed more engineering effort to update it. Why? Well, they were a little gun-shy after what happened with another promising layout proposal: CSS Regions.

CSS Regions offered a way to flow content through a series of predefined “regions” on a page, enabling really complex layouts. Microsoft released an implementation of CSS Regions early on, behind a prefix in IE 10. A patch landed support for Regions in WebKit as well. Safari shipped it, as did Chrome (which was still running WebKit under the hood at the time). But then Google backed it out of Chrome. Firefox opposed the spec and never implemented it. So the idea is currently in limbo. Even Safari will drop its experimental support for CSS Regions in its next release. Suffice it to say, Microsoft wanted to be sure Grid wouldn’t suffer the same fate as Regions before committing more engineering resources to it.

“We had implementers that immediately said, ‘Wow, this is great, we should definitely do it,’” recalled Atanassov of Grid. “But [it’s] one thing … saying, ‘Yeah this is great, we should do it,’ and then there’s the next step where it’s adding resources and paying developers to go and actually implement it.”

“There was desire from other implementers—one of the spec editors is from Google—but there was still hesitancy to actually push code,” recalled Microsoft’s Greg Whitworth, a member of the CSS Working Group. “And … shipping code is what matters.”

In an interesting turn of events, the media company Bloomberg hired Igalia, an open source consultancy, to implement CSS Grid for both Blink and WebKit.

“Back in 2013 … [we] were contacted by [Bloomberg] … because they had very specific needs regarding defining and using grid-like structures,” recalled Sergio Villar Senin, both a software engineer at and partner in Igalia. “[T]hey basically asked us to help in the development of the CSS Grid layout specification, and also [to] implement it for [Blink and WebKit].”

“[Igalia’s work] helped tremendously because then developers [could] see it as possibly something that they can actually use when developing their sites,” Whitworth added.
But even with two ready-made implementations, some folks were still concerned the feature wouldn’t find its footing. After all, just because a rendering engine is open source doesn’t mean its stewards accept every patch. And even if they do, as happened with CSS Regions, there’s no guarantee the feature will stick around. Thankfully, a good number of designers and developers were starting to get excited about Grid and began to put pressure on browser vendors to implement it.

“There was a pivotal shift with CSS Grid,” Whitworth said. “Starting with Rachel Andrew coming in and creating a ton of demos and excitement around CSS Grid with Grid by Example and starting to really champion it and show it to web developers and what it was capable of and the problems that it solves.”

“Then, a little bit later, Jen Simmons [a Designer Advocate at Mozilla] created something called Labs where she put a lot of demos that she created for CSS Grid up on the web and, again, continued that momentum and that wave of enthusiasm for CSS Grid with web developers in the community.”

Grid facilitates both traditional and (as shown here) non-traditional layouts. This is a Grid Layout example from Jen Simmons’ Labs, as seen in Edge 16. If you’d like to see it working in Edge but don’t run Windows, you can also view it in BrowserStack (account required).

With thought leaders like Andrews and Simmons actively demonstrating the power and versatility of CSS Grid, the web design community grew more excited. They began to experiment on sites like CodePen, sharing their ideas and developing their Grid layout skills. We don’t often think about it, but developer enthusiasm has the power to bolster or bury a spec.

“We can write a spec, we can go implement things, but if there isn’t developer demand or usage of the features, it doesn’t really matter how much we do with that,” Whitworth said.

Unfortunately, with ambitious specs like Grid, the implementation cost can often deter a browser vendor from making the commitment. Without a browser implementation enabling developers to tinker and experiment, it’s hard to build enthusiasm. Without developer enthusiasm, browser vendors are reluctant to spend the money to see if the idea gains traction. I’m sure you can see the problem here. In fact, this is partly what has doomed Regions—performance on mobile chipsets was another cited reason—at least for now.

Thankfully, Bloomberg willingly played the role of benefactor and got the ball rolling for this new incarnation of CSS Grid. So, with its help, Google landed an implementation of CSS Grid in Chromium 56 for Android in January of 2017. It landed its Chrome implementation in early March, just two days after Mozilla shipped its own implementation in Firefox. Before the month was over, Opera and Safari had also shipped support for CSS Grid.

Ironically, the last company to ship CSS Grid was Microsoft. But it released its implementation in Edge earlier this week.

“With features on the web platform … you’re waiting for a sweet spot,” Whitworth said, just prior to Grid’s release in Edge. “You want a solid spec, you want implementer interest, and you want tons of demand from web developers. Late 2016/early 2017 was that sweet spot. All of that happened. We upgraded our implementation and are stoked to ship it.”

“I don’t recall a feature ever shipping like CSS Grid has shipped. Every major browser will have shipped it within a matter of a single year, and it will be interoperable because we’ve been… implementing [it] behind flags, testing it, making future changes behind flags, and then when it was deemed stable, all the browsers are now shipping it natively.”

“With everybody shipping at approximately the same time,” Atkins said, “[Grid] goes from an interesting idea you can play with to something that you just use as your only layout method without having to worry about fallbacks incredibly quickly. … [It’s been] faster than I expected any of this to work out.”

What Grid means for CSS

With Grid support no longer in question, we can (and should) begin to make use of this amazing tool. One of the challenges for many of us old timers who have been working with CSS for the better part of two decades, is that CSS Grid requires a whole new way of thinking about layout.

“It’s not just attaching your margins and properties to each individual element and placing them,” Bos said. “[Y]ou can now have a different model, a model where you start with your layout first and then pull in the different elements into that layout.”

“It is the most powerful layout tool that we have invented yet for CSS,” Atkins said. “It makes page layouts so ridiculously easy. … [P]eople have always been asking for better layouts. Just for author-ability reasons and because the hacks that we were employing weren’t as powerful as the old methods of just put[ting] it all in a big old table element—that was popular for a reason; it let you do powerful complex layouts. It was just the worst thing to maintain and the worst thing for semantics. And Grid gives you back that power and a lot more, which is kind of amazing.”

“CSS Grid takes all of that complicated stuff that we had to do to [achieve] basic layouts and makes it completely unnecessary,” Etemad said. “You can talk to the CSS engine directly[—]you, yourself, without an intermediary translator.”

CSS Grid offers a lot of power that many of us are only just starting to come to grips with. It will be interesting to see where we go from here.

“I think it’s going to be transformative,” Etemad said. “It’s going to take CSS back to what it was meant to be, which is styling and layout language that lifts all of that logic away from the markup and allows that clean separation of content and style that we’ve been trying to get from the beginning.”

“I’m excited about the future of CSS layout,” Whitworth said. “CSS Grid is not the end; it’s actually just the beginning. In IE 10 … [we shipped] CSS Regions as well as CSS Exclusions. I think as web designers begin to utilize CSS Grid more and more, they’ll realize why we shipped all three together. And maybe we can continue what we did with CSS Grid and continue to improve upon those specifications. Get vendor desire to implement those as well. Get the community excited about them and push layout on the web even further.”

“I think that now we have Grid, Exclusions makes absolute sense to have,” Andrew said. “It gives us a way to place something in [a grid] and wrap text around it, and we don’t have any other way to do that. … And then things like Regions … I would love to see that progress because … once we can build a nice grid structure, we might want to flow content through it. We don’t have a way of doing that.”

“[A]s far as I’m concerned, this doesn’t stop here; this is just the start.”

Getting into Grid
Categories: thinktime

Processing negative reviews

Seth Godin - Thu 19th Oct 2017 19:10
Assumption: Some people love what you do. They love your product, your service, the way you do your work (if that's not true, this post isn't for you. You have a more significant problem to work on first). So, how...        Seth Godin
Categories: thinktime

Pages

Subscribe to kattekrab aggregator