You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A simple exercise illustrating how breakpoints work.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For the question of setting the state of 'invalid' when building interactive web apps, there are two options. Using the class of .is-invalid is an easy and common option, but semantically worthless.
HTML5 uses the pseudo element of :invalid, while this is better because we don't need to program against this, the fail is that everything is invalid until the user interacts with it when coupled with the attribute of required as shown in this example gist. There is also a JSBin version you can see too that is better for viewing on a device.
9942957
While I am comfortable with the common use case of the class of .is-invalid for the presentation of the state, I also advocate for adding all the appropriately semantic attributes.
In the end, for an invalid state we could end up with an <input> element like the following:
Set up a new Node.js project with Express >4.0: a newb's guide
And my article is deprecated!
As of just writing this, Express 4.0 was released and there are points in there that no longer matter. So, this remains as a great >4.0 article.
Node.js is the red-hot new hotness! You can't throw a stick on the internet without hitting someone talking about Node. But why? For one, it's built on JavaScript which is completely ubiquitous. So, why not build a development stack and server on JavaScript? I would argue that the installation is almost painless while the terseness of the language is not.
While you can create apps 100% from Node.js, the Express framework is a great tool that helps you solve many standard problems without having to write boilerplate code.
Node.js is here and it's not going anywhere anytime soon. So if you are new to Node.js, Express, and even JavaScript in general, this is a great newb's step-by-step guide to get started.
Life is ever changing, right? Everything around us is always in a constant state of change. You learn early either to be flexible with these winds or you resist them.
Evangelizing beyond the Rails developer
Back in 2008 I heard about this thing called Rails and a fellow developer told me about a new CSS language called 'Sass'. At the time I was working for a company that heavily leveraged Microsoft technologies and Ruby was not something that we could plug into our environment. Sass was a ncoew toy I could read about, that's as far as it went.
Fast forward just a year, I moved on and began working with a Rails team. Their first question, "You know Sass?" I said, "Nope, but it's a great time to learn!"
Since then I have been a huge advocate for the use of Sass and still continue to promote awareness. Within the Rails community, this is pretty easy to evangelize, moving away from Rails, even today it is difficult to convince people. I went on various speaking engagements, and spoke about better ways t
Since I began this group, the scope of what it means to be a front-end developer has dramatically changed. There are so many more tools in our arsenal and there is equally as much confusion.
Adding to this confusion is the growing number of front-end frameworks that have the goal in mind to make our lives easier, but fail in their delivery.
Throwing technology and frameworks at the problems are not solving any of them. What's missing from the solutions are the discussion and community involvement needed to come to conclusions that address the problems that front-end developers deal with on a daily basis.
Truth is, discussions and involvement are hard. Reaching for some off-the-shelf software that solves all your issues is easy. Thus the rise of Bootstrap. The design API for front-end development. For those who don't know, they LOVE IT. For those who do know, this is the worst tool possible.
Zurb's Foundation and Bourbon's Bitters are good starts, but not everyone solves problems these ways. We need soluti