emGee Software Solutions Custom Database Applications

Share this

Web Technologies

A Site for Front-End Development Conferences (Built with 11ty on Netlify)

CSS-Tricks - Tue, 02/12/2019 - 14:48

I built a new little site! It's a site for listing upcoming conferences in the world of front-end web design and development. In years past (like 2017), Sarah Drasner took up this daunting job. We used a form for new conference submissions, but it was still a rather manual task of basically manually editing a blog post. I wanted to keep doing this, as I think it's valuable to have a simple reference page for conferences in our niche slice of the web, but I wanted the site to be able to live on year after year with lower maintenance-related technical debt.

So this is what I did!

I wanted to get it on GitHub.

So I put it there. Part of the beauty of GitHub is that it opens up the idea of collaboration through pull requests to really anyone in the world. You need to have a GitHub account, but that's free, and you need to understand Git at least on some minor level (which is a barrier that I'd like to resolve in time), but it invites more collaboration than something like just asking people to email you content and ideas.

I wanted the content in Markdown in the Repo.

The Front Matter format, which is Markdown with some data the the top, is such a useful and approachable format. You need almost zero knowledge, not even HTML, to be able to create/edit a file like this:

Having the actual conference data in the repo means that pull requests aren't just for design or features; more commonly, they will be for actual conference data. The work of making this site full of all the best conferences is the work of all of us, not just one of us.

At the time of this writing there have already been 30 closed pull requests.

I used 11ty to build the site.

11ty is almost fascinatingly simple. It looks in one directory for what it needs to process or move to another directory. It supports my favorite templating system out of the box: Nunjucks. Plus front matter Markdown like I mentioned above.

I was able to essentially design a card that displays the data we get from the Markdown files, and then build the homepage of the site by looping over those Markdown files and applying the templated card.

11ty is based on Node.js, so while I did have some learning-curve moments, it was comfortable for me to work in. There definitely is configuration for doing the things I wanted to be doing. For example, this is how I had to make a "collection" of conferences in order to loop over them:

config.addCollection("conferences", function(collection) { let allConferences = collection.getFilteredByGlob("site/conferences/*.md"); let futureConferences = allConferences.filter(conf => { return conf.data.date >= new Date(); }); return futureConferences; }); The site is hosted on Netlify.

One reason to use Netlify here is that it's incredibly easy. I made a site site in Netlify by connecting it to the GitHub repo. I told it how to build the site (it's a single command: eleventy) and where the built site files are (dist), and that's it. In fact, that's even part of the repo:

Now whenever I push to the master branch (or accept a pull request into master), the site automatically rebuilds and deploys. Just takes seconds. It's really amazing.

Better, for each pull request, Netlify makes sure everything is in order first:

My favorite is the deploy preview. It gives you an (obscure) URL that will literally last forever (immutable) and that serves as a look at the built version of this site with that pull request.

So, not only is it extremely easy to use Netlify, but I get a bunch of stuff for free, like the fact that the site is smokin' fast on their CDNs and such.

I'm also excited that I've barely tapped into Netlify's features here, so there is a lot of stuff I can dig into over time. And I intend to!

I use Zapier to re-build the site every day.

There is a bit of a time-sensitive nature to this site. The point of this site is to reference it for upcoming conferences. It's less interesting to see past conferences (although maybe we can have a browse-able archive in the future). I like the idea of ripping off past conferences for the homepage. If this was PHP (or whatever), we could do that at runtime, but this is a static site (on purpose). Doing something like this at build time is no big deal (see that code snippet above that only returns conferences past today's date). But we can't just waiting around for pull requests to re-build the site, nor do I want to make it a manual thing I need to do every day.

Fortunately, this is easy as pie with Zapier:

Phil Hawksworth took this to the extreme once and built a clock website that rebuilds every minute.

This site wasn't just an experiment. I'd like to keep it going! If you're part of running a conference, I'm quite sure it doesn't hurt to add it to add yours, just so long as it has an enforcable and actionable Code of Conduct, and is within the world of front-end web design and development.

The post A Site for Front-End Development Conferences (Built with 11ty on Netlify) appeared first on CSS-Tricks.

Categories: Web Technologies

Quick! What’s the Difference Between Flexbox and Grid?

CSS-Tricks - Tue, 02/12/2019 - 14:22

Let's go rapid fire and try to answer this question with quick points rather than long explanations. There are a lot of similarities between flexbox and grid, starting with the fact that they are used for layout and much more powerful than any layout technique that came before them. They can stretch and shrink, they can center things, they can re-order things, they can align things... There are plenty of layout situations in which you could use either one to do what we need to do, and plenty of situations where one is more well-suited than the other. Let's focus on the differences rather than the similarities:

Flexbox can optionally wrap. If we allow a flex container to wrap, they will wrap down onto another row when the flex items fill a row. Where they line up on the next row is independent of what happenned on the first row, allowing for a masonry-like look.

Grid can also optionally wrap (if we allow auto filling) in the sense that items can fill a row and move to the new row (or auto place themselves), but as they do, they will fall along the same grid lines all the other elements do.

Flexbox on top, Grid on bottom

You could think of flexbox as "one dimensional." While flexbox can make rows and columns in the sense that it allows elements to wrap, there's no way to declaratively control where elements end up since the elements merely push along a single axis and then wrap or not wrap accordingly. They do as they do, if you will, along a one-dimensional plane and it's because of that single dimension that we can optionally do things, like align elements along a baseline — which is something grid is unable to do.

.parent { display: flex; flex-flow: row wrap; /* OK elements, go as far as you can on one line, then wrap as you see fit */ }

You could think of grid as "two dimensional" in that we can (if we want to) declare the sizing of rows and columns and then explicitly place things into both rows and columns as we choose.

.parent { display: grid; grid-template-columns: 3fr 1fr; /* Two columns, one three times as wide as the other */ grid-template-rows: 200px auto 100px; /* Three columns, two with explicit widths */ grid-template-areas: "header header header" "main . sidebar" "footer footer footer"; } /* Now, we can explicitly place items in the defined rows and columns. */ .child-1 { grid-area: header; } .child-2 { grid-area: main; } .child-3 { grid-area: sidebar; } .child-4 { grid-area: footer; } Flexbox on top, Grid on bottom

I'm not the world's biggest fan of the "1D" vs. "2D" differentiation of grid vs. flexbox, only because I find most of my day-to-day usage of grid is "1D" and it's great for that. I wouldn't want someone to think they have to use flexbox and not grid because grid is only when you need 2D. It is a strong distinction though that 2D layout is possible with grid though in ways it is not in flexbox.

Grid is mostly defined on the parent element. In flexbox, most of the layout (beyond the very basics) happen on the children.

/* The flex children do most of the work */ .flexbox { display: flex; > div { &:nth-child(1) { // logo flex: 0 0 100px; } &:nth-child(2) { // search flex: 1; max-width: 500px; } &:nth-child(3) { // avatar flex: 0 0 50px; margin-left: auto; } } } /* The grid parent does most of the work */ .grid { display: grid; grid-template-columns: 1fr auto minmax(100px, 1fr) 1fr; grid-template-rows: 100px repeat(3, auto) 100px; grid-gap: 10px; }

Grid is better at overlapping. Getting elements to overlap in flexbox requires looking at traditional stuff, like negative margins, transforms, or absolute positioning in order to break out of the flex behavior. With grid, we can place items on overlapping grid lines, or even right within the same exact grid cells.

Flexbox on top, Grid on bottom

Grid is sturdier. While the flexing of flexbox is sometimes it's strength, the way a flex item is sized gets rather complicated. It's a combination of width, min-width, max-width, flex-basis, flex-grow, and flex-shrink, not to mention the content inside and things like white-space, as well as the other items in the same row. Grid has interesting space-occupying features, like fractional units, and the ability for content to break grids, though, generally speaking, we're setting up grid lines and placing items within them that plop right into place.

Flexbox can push things away. It's a rather unique feature of flexbox that you can, for example, put margin-right: auto; on an element and, if there is room, that element will push everything else as far away as it can go can.

Here are some of my favorite tweets on the subject:

flexbox looks like it does what you want
but grid is usually what you want

— Old Guard Rupert (@davatron5000) January 25, 2019

Grid makes actual columns and rows. Content will line up from one to the other, as you ask it to. Flexbox doesn’t. Not only in the second dimension (which is easiest to talk about), but also in the first dimension. Flexbox isn’t for most of the things we’ve been using it for.

— Jen Simmons (@jensimmons) January 26, 2019

How about this:#Flexbox is for alignment. #CSSGrid is for layout.

This is almost always how I wind up using them. It allows them to preserve their relationships to one another. It also allows each to be used for its strength, even though each can do the other thing.

— Brian Haferkamp (@BrianHaferkamp) January 25, 2019

If you start constraining all your flex items with a width, then more often than not it will be easier to use grid.

— Rachel Andrew (@rachelandrew) January 25, 2019

Here's another difference, but it's not a favorite way of describing them, just fun dumb knowledge:

flexbox takes 2 passes to finish
grid takes 3

so one could say, grid is slow and flexbox is fast lol

— Adam Argyle (@argyleink) January 25, 2019

For me Grid is there to great full layout..grids...with more control over how the whole are/page comes together, whereas flexbox helps me to position and align (whether it’s in a grid or not).

For me it’s about purpose.

— Mandy Michael (@Mandy_Kerr) January 25, 2019

The distinction between the two is often blurry, especially now that we also have `gap` for flexbox. Grid is best suited for a few specific use cases (2D obviously, but also things like overlapping elements) while flexbox usually shines in simpler yet common layout requirements.

— Benjamin De Cock (@bdc) January 25, 2019

Use grid when you already have the layout structure in mind, and flex when you just want everything to fit. Layout first vs content first.

— Beverly (@aszenitha) January 25, 2019

The post Quick! What’s the Difference Between Flexbox and Grid? appeared first on CSS-Tricks.

Categories: Web Technologies

A Funny Thing Happened on the Way to the JavaScript

CSS-Tricks - Tue, 02/12/2019 - 07:07

Around this time last year, I wrote an article about the JavaScript learning landscape. Within that article, you’ll find my grand plans to learn JavaScript — complete with a link to a CodePen Collection I started for tracking my progress, and it even got dozens of comments cheering me on.

Like most people, I was ambitious. It was a new year and I was excited to tackle a long-standing project. It was my development version of losing 30 pounds (which I also need to do). But, if you follow that link to the CodePen Collection, you’ll see that there’s nothing there. If you were to scour my hard drive or cloud storage, you’d see that there aren’t any JavaScript files or projects there, either.

Over the past year, I didn’t make any progress on one of my main goals. So, what the hell happened?

A Story as Old as Time

The internet is littered with similar tweets and blog posts. Inboxes are filled with TinyLetters of resolutions and there's no shortage of YouTubers teaching anyone who will listen how to have their best year ever. But very few people follow through on their goals. This might be even more true in the design and development world, what with the plethora of new technologies, languages, libraries, and tools that hit the scene on a regular basis.

These stories all follow a similar path:

  1. Person determines major goal
  2. Person tells friends (or who knows how many CSS-Tricks visitors)
  3. Person gets distracted, overwhelmed, disinterested, or all three
  4. Goal is completely forgotten about after X amount of time
  5. Person apologizes and makes up excuses for friends (or, again, who know how many CSS-Tricks visitors)

In my experience, it's not the goal-setting or telling everyone about said goal that's the problem. It's step three above. When goals go off the rails, at least for me, it's due to three main issues: distraction, stress, and lack of interest. Barring unforeseen life events, these three issues are responsible for all those unachieved goals that we struggle with.

In thinking about my goals for this year, I decided to start first with deconstructing why I couldn’t reach the one major goal I set for myself last year. So, let’s dig into those three issues and see if there’s a way to prevent any of them happening this time around.

Distraction

Distraction seems to be the big one here. We all have a lot going on. Between job and family responsibilities, other hobbies and hanging out with friends, it’s hard to fit in new projects. As necessary as they are, all those other interests and responsibilities are distractions when it comes to our goals.

The whole point of setting a goal is carving out time to work towards it. It’s about prioritizing the goal over other things. For me, I found myself letting all of those other distractions in life work their way into my day. It was all too easy to work through lunch instead of taking that time to tackle a chapter in a JavaScript book. I would get sucked into the latest Netflix series after the kids went to bed. I didn’t prioritize learning JavaScript and I had nothing to show for it at the end of the year.

Overcoming Distraction

The key here is to block out those distractions, which is easier said than done. We can’t simply ignore the needs of our families and careers, but we need to give ourselves time to focus without distractions. For me, I’m increasingly convinced that the solution is time blocking.

Time blocking is exactly what it sounds like: You block out specific periods of time on your calendar to focus on certain tasks. Time blocking allows you to prioritize what’s important. It doesn’t force you to sit down, crack open a book, or start coding, but it gives you the time to do it.
There are a ton of articles online that go into different time blocking methods, a few of which are below:

For me, I’m going to block out specific times throughout the week to focus on learning JavaScript in 2019. I’m trying to be realistic about how much time I can invest, weighing it against other obligations. Then I’m putting those time blocks on my shared family calendar to make it clear to everyone what I’m prioritizing. More importantly, I’m making it clear that this time is for focus, and to leave the other distractions at the door.

It can also be helpful to block smaller, but just as impactful, distractions on your phone and computer. Closing out browser tabs not related to your task, silencing notifications, and clearing your desk of otherwise distracting items should be part of the routine when you sit down to start working on your task. It’s easy to scroll through Twitter, Hacker News, or even CSS-Tricks and convince yourself that it’s time well spent (that last one usually is, though) but that time adds up and doesn’t always result in learning or growing your skills like you think it will. Cutting out those distractions and allowing yourself to focus on what you want to accomplish is a great way to, you know, actually accomplish your goals.

Stress

Last year’s post lays out a landscape full of interesting articles, books, podcasts, and courses. There is no lack of things to learn about and enough resources to keep anyone busy for way longer than just a year. And, when it comes to JavaScript, it seems like there’s always some new technique or framework that you need to learn.

Combine that with all of the ancillary topics you need to understand when learning JavaScript and you end up with one of those overwhelming developer roadmaps that Chris collected a while back.

I don’t care how smart you are, that’s intimidating as hell. Feeling overwhelmed on the web is common place. How do you think it feels as someone just starting out? Combined with all the responsibilities and distractions from the last section, and you have a killer recipe for burnout.

I had originally intended to work my way through Marijn Haverbeke’s Eloquent JavaScript as a first step towards learning the language. But I also mentioned all the podcasts, YouTube channels, and newsletters with which I was surrounding myself. The intention was to learn through immersion, but it quickly resulted in feeling stressed and overwhelmed. And when I felt overwhelmed, I quickly allowed all those distractions to pull my attention away from learning JavaScript.

Overcoming Stress

Just like when dealing with distraction, I think the key to dealing with stress is to focus on one or two things and cut out all the rest. Instead of fully immersing myself in the JavaScript world, I’m going to stick to just the book, work my way through that, and then find the next resource later down the road. I’m going to intentionally ignore as much of the JavaScript world as I can in order to get my bearings and only open myself up to the stress of the developer roadmap if, and when, I feel like I want to journey down that path.

Disinterest

Flipping through any programming book (at least for a beginner) causes most people’s eyes to glaze over. The code looks overly complex and it resembles a math textbook. I don’t know about you, but I hated math class and I found it hard to get excited about investing my free time in something that felt a lot like going back to high school.

But I know that learning JavaScript (and programming, in general) is a worthwhile pursuit and will let me tackle projects that I’ve long wanted to complete but haven’t had the chops to do. So, how can I get interested in what, at first glance, looks like such a boring task?

Overcoming Disinterest

I think the key here is to relate what I learn to some subject that I find fascinating.

I’ve been interested in data visualization for a long time. Blogs like Flowing Data are fascinating, and I’ve wanted to be able to create data visualizations of my own for years. And I know that JavaScript is increasingly a viable way to create those graphics. Tools like D3.js and p5.js are first-class frameworks for creating amazing visualizations — so why not learn the underlying language those tools use?

My plan to overcome disinterest is to work my way towards a project that I want to build. Go through all the basics, trudge through the muck, and then use the concepts learned along the way to understand more advanced tools, like D3.js.

Anytime you can align your learning to areas you find interesting, you’re more likely to be successful. I think that’s what was missing the first time around, so I’m setting up targets to aim for when learning JavaScript, things that will keep me interested enough to learn what I need to learn.

It’s a Hard Road

Learning is rarely easy. But, sometimes, it’s when it’s the hardest that it pays off the most.

I’m convinced that the more we can uncover our own mental roadblocks and deconstruct them, the better positioned we are to achieve our goals. For me, my mental roadblocks are distraction, stress, and disinterest. The three work together to keep me from my goals, but I’m putting plans into motion to overcome all three. Your roadblocks may differ, but you probably have ways of dealing with them, too.

I’d love to hear from everyone how they overcame their own challenges when learning a new skill. Leave a comment below telling me your story. Sharing it may help me, and others, finally achieve what we’ve always wanted, whether it’s learning JavaScript, digging into the latest framework, or running that marathon we’ve all been putting off for so long.

The post A Funny Thing Happened on the Way to the JavaScript appeared first on CSS-Tricks.

Categories: Web Technologies

411 Length Required - Evert Pot

Planet PHP - Tue, 02/12/2019 - 07:00

Most HTTP requests that have a request body, will also have a Content-Length header indicating how big the body will be. However, this is optional for some cases, such as when Chunked Transfer Coding is used.

It’s useful for a client to not include a Content-Length header for a few different cases. For instance, a client might send a HTTP request body based on a stream.

If a server does not support this feature, it can indicate this by sending back 411 Length Required.

In a situation like this, a recourse a client might have is to buffer the entire request to determine the real length.

Example HTTP/1.1 411 Length Required Content-Type: text/html Server: curveball/0.6.0 <h1>This server requires a Content-Length</h1> References
Categories: Web Technologies

Bootstrapping the transactional data dictionary

MySQL Server Blog - Tue, 02/12/2019 - 01:47

In a previous blog post, we discussed how the initialization and restart of the MySQL server has changed between versions 5.6, 5.7 and 8.0. Now, we will take a closer look at MySQL 8.0 to explain in more detail how the transactional data dictionary is bootstrapped.…

Categories: Web Technologies

Where Do You Nest Your Sass Breakpoints?

CSS-Tricks - Mon, 02/11/2019 - 07:16

I love nesting my @media query breakpoints. It's perhaps the most important feature of Sass to me. Maybe I pick a method and do it like this:

.element { display: grid; grid-template-columns: 100px 1fr; @include breakpoint(baby-bear) { display: block; } }

That's straightforward enough. But what if my element has several sub-elements and the breakpoint affects them as well? There are different approaches, and I'm never quite sure which one I should be doing.

I could duplicate the breakpoint for each child:

.parent { @include breakpoint(desktop) { } .child { @include breakpoint(desktop) { } } .child-2 { @include breakpoint(desktop) { } } }

The compiled CSS comes out to something like this:

@media screen and (min-width: 700px) { .parent { } } @media screen and (min-width: 700px) { .parent .child { } } @media screen and (min-width: 700px) { .parent .child-2 { } }

Or, I could duplicate the children under the first nested breakpoint:

.parent { @include breakpoint(desktop) { .child { } .child-2 { } } .child { } .child-2 { } }

That results in:

@media screen and (min-width: 700px) { .parent .child { } .parent .child-2 { } } .parent .child { } .parent .child-2 { }

Or I could do a combination of the two. Neither of them feels particularly great because of the duplication, but I'm not sure there is a perfect answer here. I err a little more on duplicating the media query, as it seems less error-prone than duplicating selectors.

The post Where Do You Nest Your Sass Breakpoints? appeared first on CSS-Tricks.

Categories: Web Technologies

The ineffectiveness of lonely icons

CSS-Tricks - Mon, 02/11/2019 - 07:15

Icons are great and all, but as we've been shown time and time again, they often don't do the job all by themselves. Even if you do a good job with the accessibility part and make sure there is accompanying text there for assistive technology, in an ironic twist, you might be confusing people who browse visually, like the situation Matt Wilcox describes with his mother in this linked article.

I'm a fan of this markup pattern, including the inline SVG as the preferred icon system:

<button> <svg class="icon icon-cart" viewBox="0 0 100 100" aria-hidden="true"> <!-- all your hot svg action, like: --> <path d=" ... " /> </svg> Add to Cart </button>

Or, if the button is really a link and not a JavaScript-powered action, I'll use an <a href=""> instead of a <button> wrapper.

Direct Link to ArticlePermalink

The post The ineffectiveness of lonely icons appeared first on CSS-Tricks.

Categories: Web Technologies

Full-stack developer: What it is, and how you can become one

InfoWorld JavaScript - Mon, 02/11/2019 - 03:00

A full-stack developer is a jack of all trades and a highly sought-after job candidate. The title implies a breadth of knowledge that can be invaluable to short-staffed startups and big companies managing complex apps alike.

However, the term “full-stack developer” is controversial among developers. Some disparage the idea that anyone could be equally competent across an entire software stack, while others believe that the term has been so overused by employees and employers that it has become somewhat meaningless.

To read this article in full, please click here

Categories: Web Technologies

The badge holder function

Echo JS - Mon, 02/11/2019 - 00:47
Categories: Web Technologies

Can't Unsee

Echo JS - Mon, 02/11/2019 - 00:47
Categories: Web Technologies

Pages