    
|
Another chance to catch the most interesting, and important, articles from the previous week on MIT Technology Review.
]]>|
|
|
|
|
|
|
|
You might be familiar with elements collapsing vertically. If an element only contains other elements that are floated, the parent element will collapse to zero height. We often employ the clear fix for that. But if an element doesn't contain anything, it can collapse horizontally as well, which can be quite awkward for layout.
Here's an example of some HTML for a three-column layout.
<div class="grid grid-bad">
<div class="col col-1-3"></div>
<div class="col col-1-3"></div>
<div class="col col-1-3">
I'm the last column.
</div>
</div>Floats are still probably the most practical way to handle columns for now. We might use a really simple grid system like this:
.col {
float: left;
}
.col-1-3 {
width: 33.33%
}If you're like me, you might have a mental model of that something like:
But you might be surprised. Because those first two columns are empty and have nothing else to give them any height, they collapse horizontally. The last column, because it does contain some content, will respect it's width, but appear along the left, because the two columns before it have collapsed.
I came across it recently in a situation where the content of a column was loaded with Ajax. The column otherwise contained nothing, so until that Ajax call was successful and the content added, it was collapsed in width. When the content did come in, it shifted all the columns after to the right. Awkward.
See the Pen gBCfl by Chris Coyier (@chriscoyier) on CodePen
It may never come up for you. Perhaps your columns always contain some kind of content. No big deal then. But if you are making a grid framework, even for yourself, you should probably consider this scenario.
The columns need some kind of something to give them at least 1px of height. With that, they won't collapse in width. Sometimes columns have padding, that works fine. If a column has top or bottom padding, or top or bottom border, you're set. If not for that, you can just set a min-height.
/* Any of these with positive lengths will work */
.col {
border-top: 1px solid white;
border-bottom: 1px solid white;
padding-top: 1rem;
padding-bottom: 1rem;
min-height: 1px;
}So yeah, not super common, but if you're making a grid system you might as well have something in there to prevent collapsing.
Make Sure Your Columns Don’t Collapse Horizontally is a post from CSS-Tricks
]]>
We love web design resources, and we love them even more when they’re absolutely free. so each month we scour the Internet to bring you the very best free resources for web designers and developers.
This month we’ve included PSD resources, social network buttons, ribbons, mockups, guis of music players, app concepts, icons, plugins, fonts, templates, and much much more for you to amuse yourself creating everything you want, from personal blogs and experiments, to professional projects for your clients.
15 ribbons for all your projects.
Unique linear font family.
Fully editable vector psd.
Simple dashboard UI with all kinds of design elements.
Realistic PSD graphic ribbons.
Innovative music application interface.
A collection of different devices in flat style.
Condensed geometric sans serif font with uppercase, small caps, numbers & symbols.
Free PSD app concept.
A modern humanist sans serif made for the screen.
Theme for pages about cooking.
Generate SVG backgrounds for web projects.
A handdrawn serif web font.
250+ scalable vector icons for developers.
40+ line weather icons for GUIs and mobile projects.
Retro styled typeface.
Javascript API for gmail.
Useful package of 32×32 icons for office apps.
SEO enhanced WordPress theme.
Wide and clean theme for personal web pages.
Useful pack of line icons for dark backgrounds.
An elegant serif font.
Icons for all kinds of purposes.
AI file with elements portraying web, tablet and mobile devices.
Awesome looking interface with several types of visual statistics.
Decorative sans serif family of three completely different weights.
A library of animated SVG icons for the web.
100 simple yet beautiful line icons.
Theme for small and medium businesses.
A set of various mockups for presentations.
Flat portfolio template PSD.
A set of daily icons.
All caps typeface for large point settings.
Widget with animated buttons.
50+ small flat and colorful icons.
Image lazy loading.
6 high resolution textures for all your projects.
20th century geometric font.
Modern timeline slider made in CSS3.
Site search engine plugin.
Slab rounded font.
Cool set of mobile gesture icons.
Minimal homepage PSD.
Font made combining big, thick serifs.
Package of 20 brilliant social media badges.
Versatile plugin that has several uses.
Textured set of icons with a 5 o’clock long shadow.
Plugin to flex images like paper.
Essential elements to showcase your brand.
Which of these freebies is your favourite? Have we missed a resource you rely on? Let us know in the comments.
| Become a Successful eBook Author with ‘Authority’ – only $19! |  |
|
|
 |
A while back, I wrote a post about starting an open-source project. The focus of that article was on starting an open-source project as an individual. I received a lot of positive feedback and also some questions about how the process changes when you’re open-sourcing a project at work.
Open source projects are always a team effort, and they always require a dedicated commitment to the project. Image credit: open source way
Many companies are starting to investigate and participate in the open-source community, and yet few guides for doing so exist. This article focuses primarily on the process of open-sourcing a project at work, which brings with it other concerns and decisions.
Before delving into the how, it’s useful to step back and talk about the why. Why is it that so many companies have or are starting to establish an open-source presence? There are actually a number of reasons:
There are many more reasons why companies are choosing to open-source, but these are the primary drivers. Therefore, the process of open-sourcing a project must be aligned with these goals while protecting the company’s interests.
Suppose someone at your company wants to open-source something. This has never happened before and you’re not sure what to do. Do you just put it up on GitHub? Announce it in a press release or blog post? How do you know that the code is OK to open-source? There is a lot of planning to do, and it all starts (unfortunately) with the legal department.
Giving away company assets is as much a legal issue as anything else. The very first conversation should be with an appropriate member of your company’s legal team to discuss the ins and outs of open-sourcing. In larger companies, one or more intellectual property (IP) attorneys are likely on staff or on retainer; in smaller companies, this conversation might start with the general counsel. In either case, it’s important to lay out exactly what you want to do and to clarify that you’d like to formalize a repeatable process for open-sourcing projects.
The primary legal concerns tend to be around licensing, code ownership and trade secrets. These are all important to discuss openly. Because many companies have done this already, you should have a fair amount of evidence of how other companies have established their processes. The most important thing is to engage the legal department early in the process and to have a champion on the legal team who you can work with should any issues arise.
One of the first topics of discussion should be which open-source license the company will use as its standard. Leaving the team for each project to decide for itself which license to use is a bad idea, because a lack of awareness could quite possibly lead to two projects from the same company having incompatible licenses. Decide up front exactly which license to use, and use it for all open-source projects in your company.
I touched on the different types of licenses in my previous article (also, see “Understanding Copyright and Licenses”). In general, companies tend to standardize either the three-clause BSD license or the Apache license. Very rarely will a company standardize the MIT license, because the standard MIT license doesn’t contain a clause that prevents use of the company’s name in advertisements for software that makes use of the project. The Apache license has additional clauses related to patent protection, which some companies prefer.
The ultimate choice of a license typically comes down to legal considerations on the nature of the code being released. The philosophical implications of which license you choose are not important; using the same license for all projects in your company is important.
The next topic of discussion should be to define an outgoing review process. Just putting code out in the public without some sort of review is neither safe nor sane. In general, a request to open-source a project should be reviewed by the following:
Exactly how an outgoing review gets started tends to be company-specific. It could be done by submitting a request to a mailing list, filling out a form or just setting up a meeting. How it’s implemented isn’t as important as the fact that the review occurs and is done quickly. So, setting a deadline for a response is a good idea. Depending on the size of the company, this could range from a few days to a few weeks, but setting up the expectation ahead of time helps to alleviate any scheduling issues.
One part of the process that is often forgotten is figuring out rules for accepting external contributions. Open-sourcing a project is basically a way of saying, “Hey, we’d love to have you fix our bugs!” Part of the point is to get people interested enough to want to contribute to the project. Establish a process so that you know how and from whom external contributions may be made.
When building something, accepting external contributions can significantly benefit the project, but you need to establish a process for contributions first. Image credit: open source way.
The company should require a contributor license agreement (CLA) to be signed before accepting contributions from external developers. A CLA is a legal document that typically states a few things:
Take the Node.js CLA. It’s a pretty straightforward form that defines the expectations for contributors and asks for the contributor’s name and other information. These days, asking for someone’s GitHub user name as well is quite common (to help automate the process of checking CLAs for commits).
The CLA will be important should any legal action be taken against your company as a result of the code contained in the project. Because the company is the maintainer of the project, any legal action would likely be directed at the company itself, rather than any individual contributor.
CLAs are sometimes controversial, and some developers refuse to sign them. That’s an acceptable loss to protect yourself and your company from the legal risks of open-source projects. Those who are familiar with the open-source community and the reason behind CLAs will be more than happy to sign on and contribute to your project.
An overlooked part of the open-source process is maintaining the project once it’s been published. Many developers (and some companies) view the step of open-sourcing a project as the end of the process — they’ve already spent considerable time creating software that they now want to share with the world. In truth, open-sourcing a project is the beginning of a journey. The act of sharing now makes it, effectively, communal software, and you can now expect the project to be discussed and to evolve as a whole.
Once a new project is open-sourced, eventually you’ll start receiving suggestions, requests and pull-requests. Maintenance is a task that is often overlooked in open-source projects. Image credit.
Many companies that are new to the open-source community make the mistake of publishing their code and leaving it behind. Issues are left unresolved and unanswered, road maps are not shared, pull requests are ignored, and there is no way to get in contact with the people behind the project. As much as open-source projects can enhance your technical brand, leaving projects in this state can hurt it.
Once you’ve open-sourced a project, you must commit to maintain it. Even stable software will have bugs, and some of those bugs could be found by people outside of your company. If you have no intention of interacting with anyone outside of the company on this project, then you might want to consider simply distributing the compiled binary or library freely, and not actually open-sourcing the code.
While there are no established rules for maintaining a project, here are some guidelines I follow:
An open-source project very quickly takes on a life of its own once released. If a community forms around the project, then it could take up more and more of your time. That’s why a commitment to maintain the project needs to be a part of the open-sourcing process. Letting a project languish without any attention sends a horrible message to those outside of your company and will discourage people from contributing.
Most open-source projects, whether by individuals or companies, are started with the best of intentions. Typically, the goal is to share learning and code with the world. However, the Internet is littered with abandoned projects. If your project ends up like this, it could hurt your and your company’s reputation. Projects slowly decay over time and can usually be identified by one or more of the following characteristics:
Keep an eye on these patterns in your own project. If you recognize the warning signs, then you’ll have to decide what to do with the project. Either someone else should become the maintainer or it’s time to end-of-life the project.
At some point, you or your company might find that there is no longer interest in maintaining the project. This is a natural evolution of software — sometimes a project outlives its usefulness. When this happens, you need to appropriately end-of-life the project.
End-of-lifing typically starts with a public announcement that the project is no longer being actively maintained (along with a post in the project’s README file). The announcement should address the following:
Ultimately, you might decide to delete the repository completely. While being able to see all of a company’s projects, even those that have been end-of-lifed, is sometimes nice, that comes at a cost, and so removing repositories from time to time might be prudent. In doing so, be certain that you have effectively communicated that the project is going away, and give at least 30 days notice to allow others to fork the project if they are so inclined.
Open-sourcing projects at work is a great initiative for many reasons. When done correctly, an open-source presence will do a lot to promote your company and its employees. Active open-source involvement signals your company’s willingness to interact with the technical community and to contribute back, both signs of a strong technical brand.
On the other hand, a poor open-source presence is worse than no presence at all. It signals general laziness or apathy towards a community of developers, a community that might very well want to help your project succeed. Few things are as demoralizing as trying to work on an open-source project that has been abandoned. Don’t be that company.
(al)
© Nicholas C. Zakas for Smashing Magazine, 2013.
]]>|
|
|
|