The dev ops guy on our team comes up with some creative and hilarious passwords for our web servers. Every time he sends me a new ssh credential, it inevitably cracks me up. He follows the multiword approach with some special characters sprinkled in.
When inspiration hits, it is usually when the combination of two or more things collide together in your brain and give birth to something else. This is what happed to me when I was walking around the 18th floor and, boom!, I had an idea. A few days later, I launched Passwords for the Manly Man.
I’ve written before about how I come up with ideas. The key to shipping your ideas out into the world is to strike while the iron is hot. Don’t overthink it, just do it. I’ve posted before about my criteria for the types of ideas I like to pursue. It is good to have that, but ultimately what you want is to come down with a bit of the madness over an idea and just execute.
Go to that url and use the Capture Webpage Screenshot Chrome Extension to take a screenshot. After a few seconds of processing time, you will have yourself a nice looking screen capture of your website across a variety of screen sizes (like this).
If you’d like to customize the screen sizes, click the customize button in Responsivator and adjust the frames settings
Note: This article has been updated since originally published. The tool previously recommended is no longer available (as you may notice in the comments).
Are you looking to get some projects up on Github? There are a few different approaches you can take. Here is mine.
First, you need some projects. Front end projects work best for Github project pages. If you have ideas that involve server-side, you will need to host that aspect of your project somewhere else and you would never want to host any api keys or security-sensitive content on a public Github page (obviously).
For my projects, I like to have my project demo page and the master branch of the code be the same. So, start with your master branch and build it out. There are lots of tutorials on Git and Github, so find one that works for you if you want help getting started.
When your demo is ready, the next step is to create a Github Project Page. This can be accomplished simply by creating a new gh-pages branch that is identical to your master branch.
git checkout -b gh-pages
git push origin gh-pages
As you make changes to the project, keep your gh-pages and master branches in sync. The easiest way to do this is with git rebase.
For more information on this pattern, read these posts by Lea Verou and Oli Studholme. One thing you could try is to make a project and use it as a git/github playground for experimentation.
So, you have your first project page. Now just rinse and repeat. Once you have a few project pages, you should make them a fancy landing page home for them. For example, I have johnpolacek.github.io for my projects. To create one of these, simply create a new repo that follows the naming scheme yourgithubname.github.io and build out a nice web page. When you are all set, commit and push to master and you are done.
If you’d like to have your project pages be on a custom non-github domain, Github has a nice help page devoted to that. (Github makes everything so easy – Thanks Github!)
One benefit to having your content on a github domain is superior search rankings. Because of its massive popularity, Github ranks high for authority. This means that if you keep your code projects on Github, and insert links to your other content (blog, twitter, etc.) you will get some nice Google juice out of it.
Not all of your projects will get attention, and that’s ok. Remember, everyone has to start somewhere. Just keep pushing code and improving your skills. Good things are bound to happen. Most importantly: Have fun!
Like many people, I was caught off guard when Google announced it was shuttering Reader. I use it every day, combined with iGoogle, another property that is headed for sunset. Are you, like me, a Google refugee?
It used to be, I could just rely on the fact that if a piece of web technology was by Google, then it was probably the right one to use. I’d like to thank Google for liberating me from this notion. There are lots of great apps out there that have trouble competing in the shadow of Google’s subsidized apps. In the case of Reader, there were a number of great feed readers that are now getting a chance. For me, I am going with Feedly, because it is well designed and has a great mobile app.
As far as the notion of a next gen web portal, iGoogle was a pretty good solve. With a few scrolls and a few glances, I could quickly catch up on news, social feeds, email and reddit. In this space, there don’t seem to be as many worthy competitors. Netvibes seems slightly inferior to iGoogle at this stage, but if enough people start developing better widgets for it, that could change. I hope so, because I’ve started using it.
I feel like there is room for an order of magnitude improvement in this space. A web service that works on phone, tablet and desktop that brings together all the content that I care about. I could see a company like app.net growing into something that can fill that role. More likely, I expect the browser itself will take the tired concept of the homepage, and evolve it into an AI-driven dashboard for your life. Yes, please!
Update: March 20: Another service that I have used for awhile that you Google Reader refugees should check out is Prismatic. It is a great service that automagically pulls in content for you based on social services you already use as well as user settings you can configure. Great for discovering new content not in your normal feeds.
Idea Realification is about taking what’s in your head and making it happen. I am not claiming to be the world’s foremost expert on this topic, but I have managed to release quite a lot of projects over the last year or so. People have asked me how I get so much done. When I put up my Developing in the Open post, it was mentioned that I forgot the most important part, the idea.
I have ideas all the time. I think most people do. Having ideas is the easy part. All it takes is inspiration, and that has never been easier to come by than right now. Look around on the internet, listentopodcasts, watch TED, or do some traveling. Inspiration is everywhere. So if being inspired is your problem, then I don’t know what to tell you.
So, let’s assume you have ideas. That is the easy part. How do you turn an idea into something real? The answer seems simple. You get to work on it. Yet, taking an idea, turning it into a project and then finishing it is not as easy as it sounds.
I’ve found the best approach is to first organize my ideas. Rather than just jumping on an idea right away, aimlessly jumping from one inspiration to another, take some time to let it percolate. See what sticks.
I use Trello for this purpose. Every time an idea pops in my head, I create a Trello card for it and throw it on my ideas board. I am constantly adding and managing my list of ideas.
Deciding which idea to work on is the most important part. Picking the right idea will give you the greatest probability of crossing the finish line. The key I have found is to have a set of filters. Filters act as a set of criteria that you can use to evaluate which ideas are best for you.
Here are the filters that I currently apply to my ideas:
Fun. Whether it contains an element of humor or some playfulness in the design, I’ve found that for me to remain enthusiastic about an idea, there has to be a certain amount of fun involved.
Bite-Sized. I like smaller projects that I can finish quickly. If an idea is too big or too ambitious, I’ve found that it will fizzle out (at least for me). If I have a larger scale idea that I really like, I will try to break it down into smaller bites.
Recyclable. It gives me extra incentive when working on an idea if it is something that will continue to be of use to me.
Passion-Inducing. Does the idea inflict me with the madness? You know that thing where you can’t stop thinking about an idea. This is essential!
So, those are my filters. They won’t work for everyone. I encourage you to find your own. Maybe you like projects that involve data. Maybe it important to you to work on projects you can pull off solo, or maybe being collaborative is what you’re all about. Maybe you are really into projects involving hardware like lasers and/or robots. Or are more artsy. Maybe making money is a big priority.
Whatever the case may be, I recommend managing an ever-evolving list of ideas, using your filters to help rank them and then just letting the madness consume you as you knock out one idea after another.
Some of you may be thinking, “Just what the world needs, another CSS grid framework.” People understandably are asking me what makes this approach different.
Well, it isn’t really all that different from other grid frameworks you may have come across. It shares similar functionality to responsive grid systems like Zen Grids and Profound Grid in that it makes heavy use of media queries to allow for great layout flexibility.
Where it differs is it adds its grid classes to the markup, rather than the css (or scss). I prefer this approach because I find it to be self-documenting and expressive.
What I mean by ‘self-documenting’ is that I can look at the markup and immediately understand the layout behavior, without having to search through css (or scss) files. I don’t have to try to remember which class has which mixin or inherits from what.
I find it to be more ‘expressive’, because I can add or change these classes around to quickly change layouts on the fly. I do a lot of prototyping, and I’ve found this system to work great for that.
Now, that isn’t to say there aren’t drawbacks. You can wind up with a lot of divs. You will be using non-semantic classes. Other grid systems adhere more closely to OOCSS principles. For me though, I keep my grid/structure classes separate from the content classes. I let the grid do what it is supposed to do, and construct the scaffolding for the page. Then, I create the content ‘modules’ that have their own css to describe how they occupy their container (their grid). When I’m building out my widgets and so forth, I try to stick to OOCSS principles.
To sum up, I think of content as ‘objects’ and the page as scaffolding for those objects.
This is my current approach, but I don’t expect it to be right for everybody. In the future, I may change my mind and do things differently. As front end web developers, we must always be re-evaluating our craft.
There have been a lot of great sites popping up these days that are incorporating SuperScrollorama or SuperScrollorama. It is especially cool to see it spread to other countries, like on The Black Sparrow, a restaurant website in New Zealand. It is even being used on on websites where I don’t speak the language, like Land Een Job!. Luckily there is Google Translate!
And it is looking very good for 2013 (already got it started with controldeck.js). I’m lucky to get to work with a bunch of talented devs, and the plan is to join forces to pull off some cool stuff. Stay tuned.
No matter the skill level, we all need to learn constantly just to keep up with the relentless pace of change. It doesn’t matter whether you are great, or even good. Trying to get better is what matters. Giving a damn about your craft matters. If you do, then you have what it takes.
A little over a year ago, my second son was born. Having kids changes your perspective. The need to provide for them is highly motivating. Last December, I stayed home to spend time with my family, and work on some projects. Having seen some interesting HTML5 presentation frameworks, I decided make one of my own.
Now, I’m always looking for opportunities to build things I can share on Github. Even if I make something that turns out to be a dud, it forces me to write better code. To comment or write documentation so people (perhaps my future self) can use what I’ve created.
I sometimes wonder why more of us don’t develop in the open. Maybe some devs think what they’re doing isn’t interesting, or good enough. That it takes too much time to clean up their code, write docs or create a project page.
The web can be a harsh, judgmental place. For me, the year I’ve had has been a great success. Still, it would have been easy to get bogged down by negative comments, frustrated by issues and bug reports, or embarrassed by code mistakes. Will people say you are doing it wrong? Of course! I have literally been told I am ruining the internet.
Put aside those doubts and negative feelings. If it takes too long to make an amazing project page, then don’t. If writing documentation is taking forever, then write less and let your code do the talking.
Developing in the open isn’t about being perfect. It is about getting yourself out there. Do cool stuff, share it and talk about it. Over and over. It is about getting better. It is about being a part of something bigger than the desk you sit at. So, get out there and mix it up. You’ll be glad you did.