Where the design community meets.
Technical Director at Platform Q Joined over 5 years ago
Ryan hasn't posted any stories yet.
I never really understood the obsession with optimising 'everyday carry', until I got the Bellroy Classic Backpack Plus – it's £159, so certainly not cheap, but every penny has proven worthwhile, the layout is so well thought-out and the manufacturing quality is second-to-none
https://youtu.be/74kPEJWpCD4?t=74 – the 'exploding coloured chalk' on-screen video looks very familiar...
This may not be the very latest practice but I follow what Zachleat calls "Critical FOFT with data-uri" (https://www.zachleat.com/web/comprehensive-webfonts/#critical-foft-data-uri)...
I embed the normal weight/style of my font in my inline CSS as a data-uri, this allows the browser to render the majority of the text properly, rendering faux italic / non-normal weights using this base font where necessary.
Then I asynchronously load the rest of my CSS, which contains url-based references to the specific weights & styles (e.g. italic, bold, light), causing the browser to repaint with the proper font.
If you have a server/CDN supporting HTTP/2 (most popular CDNs support this now) you could push those files, defeating the need for inline CSS (or data-uri included fonts) and simply reference them as normal in your code.
In future, the ultimate solution, once browsers catch up, would be to combine
font-display: swap with HTTP/2 pushing of the fonts.
I haven't had any bugs for a long time (pre-v3?), nor have I heard any complaints from my team.
We use it in a scrum-style, we have one board which is an ice box (project backlog) for future ideas, then a new board for each sprint, within the sprint we have the sprint backlog, in-development, in-testing and complete.
At the start of each sprint, we copy the relevant card from the ice box to the sprint backlog, then our designers & developers progress them along the lists in the sprint board.
At the end of the sprint, a retrospective can be made on what's complete, what didn't make it etc.
http://webplatformdaily.org/ - great weekday roundup of tools, techniques, discussions, updates
I think a lot of the resistance is due to information overload. Teaching people about branching, merging, rebasing, et al, is a fool's errand when they haven't previously used source control, or even any command line interface, on a regular basis.
Let's just try grasping creating a repo, committing changes, and publishing them to remote repos (Github / Bitbucket). This will allow people to become acustom to the terminal and just a handful of Git commands to integrate version control into their own workflow, before being bombarded with the more technical commands which create team-based workflows.
To directly answer your questions:
Do you use/don't use a GUI client for it?
No, the CLI is well-written and GUI diagrams just confuse the matter, they force a visual mapping to the workflow that may differ to what's in people's heads.
Do you think it's worth it for small projects?
It's worth it for anything. It's just about educating people so they find it so easy for "should I use Git for this?" to be a non-question.
Do you think it's for everyone?
Everyone who works in the creative / tech space: absolutely. It just needs to be taught in the right manner.
I've used both. Middleman is more flexible, Jekyll is great if you want to get a static blog running very quickly, but Middleman's blog plugin also handles that.
My typical Middleman setup includes:
All of which is natively supported or as simple as including additional gems and configuring the plugins.
Middleman also has the asset pipeline from Rails which makes it incredibly powerful, especially when paired with Rails-Assets.org so you don't need to copy-paste external libraries into your project.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.