phunkwerk

(Better) Tabs with Round Out Borders | CSS-Tricks

Fri, 13 Jan 2012 01:42:00 -0800

via css-tricks.com

Permalink | Leave a comment »

Never create Ruby strings longer than 23 characters - Pat Shaughnessy

Thu, 05 Jan 2012 02:11:00 -0800

via patshaughnessy.net

Permalink | Leave a comment »

Bug Prediction at Google | Google Engineering Tools

Thu, 15 Dec 2011 02:40:00 -0800

Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.

However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.

In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.

via google-engtools.blogspot.com

Permalink | Leave a comment »

Twitter / @climagic: mv {E,e}ecummings.txt # Ch ...

Tue, 13 Dec 2011 00:28:00 -0800

mv {E,e}ecummings.txt # Change the case (to lowercase) of the first letter E of a filename using brace expansion.
— Command Line Magic (@climagic) December9, 2011

via twitter.com

Permalink | Leave a comment »

Opperator Blog : Forget Apps, Create Libs

Mon, 12 Dec 2011 12:41:00 -0800

While you’re building your application, chances are you’ll run into more than a few times where you write some kind of library-esque code that you then, of course, drop into a lib folder somewhere. Sure, it’s pretty reusable and you may want it in another project someday, but it’s just one file, surely it’s not worth the headache of releasing it as open source, right?

Wrong. Every piece of library code living inside your application is a piece of code that you are solely responsible for maintaining. Even if it’s just one file it can often be worth it to publish it as open source just to keep it out of your application.

via blog.opperator.com

Permalink | Leave a comment »

24 ways: Displaying Icons with Fonts and Data- Attributes

Mon, 12 Dec 2011 08:35:00 -0800

via 24ways.org

Permalink | Leave a comment »

The Big Question: Are You Better Than Yesterday?

Thu, 08 Dec 2011 07:11:00 -0800

via fourhourworkweek.com

Permalink | Leave a comment »

Ruby on Rails Guides: Ruby On Rails Security Guide

Thu, 08 Dec 2011 06:06:00 -0800

This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please mail me, Heiko Webers, at 42 {_et_} rorsecurity.info. After reading it, you should be familiar with:

via guides.rubyonrails.org

Permalink | Leave a comment »

SANS: CWE/SANS TOP 25 Most Dangerous Software Errors

Thu, 08 Dec 2011 06:01:00 -0800

The Top 25 Software Errors are listed below in three categories:

Software Error Category: Insecure Interaction Between Components (6 errors)

Software Error Category: Risky Resource Management (8 errors)

Software Error Category: Porous Defenses (11 errors)

via sans.org

Permalink | Leave a comment »

Don't Be A Free User (Pinboard Blog)

Wed, 07 Dec 2011 01:24:00 -0800

Were you a big Gowalla fan? Did you like Dodgeball? Did you think Trunk.ly (gasp!) was better than Pinboard? Did you make a lot of contributions to Nextstop? Do you miss Aardvark and EtherPad? Did "I Want Sandy" change your life?
These projects are all very different, but the dynamic is the same. Someone builds a cool, free product, it gets popular, and that popularity attracts a buyer. The new owner shuts the product down and the founders issue a glowing press release about how excited they are about synergies going forward. They are never heard from again.
Whether or not this is done in good faith, in practice this kind of 'exit event' is a pump-and-dump scheme. The very popularity that attracts a buyer also makes the project financially unsustainable. The owners cash out, the acquirer gets some good engineers, and the users get screwed.
To avoid this problem, avoid mom-and-pop projects that don't take your money! You might call this the anti-free-software movement.

via blog.pinboard.in

Permalink | Leave a comment »

Aumann's agreement theorem - Wikipedia, the free encyclopedia

Thu, 01 Dec 2011 07:37:00 -0800

Aumann's agreement theorem says that two people acting rationally (in a certain precise sense) and with common knowledge of each other's beliefs cannot agree to disagree. More specifically, if two people are genuine Bayesian rationalists with common priors, and if they each have common knowledge of their individual posteriors, then their posteriors must be equal.^[1]

A question arises whether such an agreement can be reached in a reasonable time and, from a mathematical perspective, whether this can be done efficiently. Scott Aaronson has shown that this is indeed the case.^[2]

Of course, the assumption of common priors is a rather strong one and may not hold in practice. However, Robin Hanson has presented an argument that Bayesians who agree about the processes that gave rise to their priors (e.g., genetic and environmental influences) should, if they adhere to a certain pre-rationality condition, have common priors.^[3]

via en.wikipedia.org

Permalink | Leave a comment »

ColRD: Gradient Creator

Thu, 01 Dec 2011 05:51:00 -0800

Check out this website I found at colrd.com

Permalink | Leave a comment »

Periodic Table of the Elements - Josh Duck

Tue, 29 Nov 2011 08:28:00 -0800

HTML5 Elements

The table below shows the 106 elements currently in the HTML5 working draft and two proposed elements (marked with an asterisk).

Share this

via joshduck.com

Permalink | Leave a comment »

Watch a VC use my name to sell a con. | jwz

Tue, 29 Nov 2011 07:30:00 -0800

Normally I just ignore navel-gazing tech-industry articles like this, but people keep sending it to me, so I guess this guy is famous or something. Michael Arrington posted this article, "Startups Are Hard. So Work More, Cry Less, And Quit All The Whining" which quotes extensively from my 1994 diary.
He's trying to make the point that the only path to success in the software industry is to work insane hours, sleep under your desk, and give up your one and only youth, and if you don't do that, you're a pussy. He's using my words to try and back up that thesis.
I hate this, because it's not true, and it's disingenuous.
What is true is that for a VC's business model to work, it's necessary for you to give up your life in order for him to become richer.
Follow the fucking money. When a VC tells you what's good for you, check your wallet, then count your fingers.
He's telling you the story of, "If you bust your ass and don't sleep, you'll get rich" because the only way that people in his line of work get richer is if young, poorly-socialized, naive geniuses believe that story! Without those coat-tails to ride, VCs might have to work for a living. Once that kid burns out, they'll just slot a new one in.
I did make a bunch of money by winning the Netscape Startup Lottery, it's true. So did most of the early engineers. But the people who made 100x as much as the engineers did? I can tell you for a fact that none of them slept under their desk. If you look at a list of financially successful people from the software industry, I'll bet you get a very different view of what kind of sleep habits and office hours are successful than the one presented here.
So if your goal is to enrich the Arringtons of the world while maybe, if you win the lottery, scooping some of the groundscore that they overlooked, then by all means, bust your ass while the bankers and speculators cheer you on.
Instead of that, I recommend that you do what you love because you love doing it. If that means long hours, fantastic. If that means leaving the office by 6pm every day for your underwater basket-weaving class, also fantastic.

via jwz.org

Permalink | Leave a comment »

New Ruby 1.9 Features, Tips & Tricks - igvita.com

Mon, 28 Nov 2011 03:35:00 -0800

Ruby 1.9 packs in a lot of new and improved features at all levels: it introduces a few new syntax constructs, the built-in libraries have been updated with hundreds of new methods and classes, it adds language level support for characters encodings, it ships with an entirely new virtual machine, and the list goes on. If you haven't already, you should seriously consider upgrading to Ruby 1.9 as it is a definite step up from the previous versions in all respects.

For the most part, you could upgrade from Ruby 1.8.x and remain blissfully unaware of the many updates and improvements within the language - but what fun would that be? For the curious, Ruby 1.9 Pickaxe is probably the single best resource to get yourself up to speed. To give you a flavor, below is a list of my favorite 30 tips, tricks and features - feel free to clone the gist and add your own!

via igvita.com

Permalink | Leave a comment »

Configuration for Rails, the Right Way | The Carbon Emitter

Thu, 24 Nov 2011 04:33:00 -0800

I still see people promoting various gems and plugins to handle miscellaneous configuration elements for your application. One little known secret is that Rails 3 allows you to define your own configuration elements trivially.

via blog.carbonfive.com

Permalink | Leave a comment »

Open Source (Almost) Everything

Wed, 23 Nov 2011 01:54:00 -0800

When Chris and I first started working on GitHub in late 2007, we split the work into two parts. Chris worked on the Rails app and I worked on Grit, the first ever Git bindings for Ruby. After six months of development, Grit had become complete enough to power GitHub during our public launch of the site and we were faced with an interesting question:

Should we open source Grit or keep it proprietary?

via tom.preston-werner.com

Permalink | Leave a comment »

Years of irrelevance - (37signals)

Tue, 22 Nov 2011 06:09:00 -0800

Which leads me to my point: Requiring X years of experience on platform Y in your job posting is, well, ignorant. As long as applicants have 6 months to a year of experience, consider it a moot point for comparison. Focus on other things instead that’ll make much more of a difference. Platform experience is merely a baseline, not a differentiator of real importance.

In turn that means you as an applicant can use requirements like “3-5 years doing this technology” as a gauge of how clued-in the company hiring is. The higher their requirements for years of service in a given technology, the more likely that they’re looking for all the wrong things in their applicants, and thus likely that the rest of the team will be stooges picked for the wrong reasons.

via 37signals.com

Permalink | Leave a comment »

Subsets of Design: Logic behind Voodoo

Tue, 22 Nov 2011 04:55:00 -0800

Design is how it works.
‘It’ as in everything. How you work, how the tap works, how the female brain works.
Design solves problems. And making something look more appealing is just very minute part of the problem. (Thus design is not just how it looks). It’s like sexual attraction, seems like it’s visual but there is a lot of logic and science behind it.
Let me explain different parts of design. Especially design for digital medium. With a hope that design might become a logical process and not a voodoo.
Now some definitions of prevalent design sub-sets:
Intention
Information Architecture (IA)
User Interface (UI) Design
Visual Design
User Experience (UX) Design

via 64notes.com

Permalink | Leave a comment »

A crash course in UX | richoakley.com

Mon, 21 Nov 2011 05:15:00 -0800

I was skeptical. ‘Design’ is not a word I’m entirely comfortable around. Almost entirely because I’m not naturally very good at it. And yet I found myself signed up – by my doing, too – to spend a summery Cape Town Saturday at a workshop. The workshop in question is part of Ogilvy’s Digital Marketing Academy series and Rian van der Merwe, the Head of User Experience (or something like that?) at Kalahari.net, headed up the training for the day. And was I in for a surprise…

‘Design’ is a word that conjures up an impression of artistry and creativity in the more traditional sense. Alternative and eccentric individuals with shaggy here and a ‘vision’ of what they’re working on. Not me, in other words. My day is determined by a self-assembled to-do list and even though I can consider myself ‘creative’ in an ability to come up with new ideas and the like, I have never been the sketching type. Not that it isn’t something that interests me, by any degree. I know a great design when I see it, and experiencing a great design gives me a great deal of satisfaction.

Perhaps this was the most encouraging take-out from the UX Workshop. That it is far more methodological a process than I realized. Far more accessible. UX design is almost entirely driven by a set of rules and methodologies which can be evenly applied to emphatically improve the way a user experiences a site. They are neither difficult to understand nor particularly difficult to implement, and once you’re aware of them, it makes for a much-improved approach to the way you think about and design products. And makes it obvious just how little thought some other (and reputable) brands and individuals have invested in the same.

But why bother worry about ‘user experience’ at all? While it come across as an onerous process at first thought, it actually provides the opportunity to vastly reduce the time and effort that is put into a product. Requirements are clearer, and following a set of principles guides design and allows the development of a product to happen at a much more rapid rate. Once launched, an improved experience provides more product value to each user, and guarantees an extended product life. Essentially, it’s a no-brainer.

So how do you get started?

via richoakley.com

Permalink | Leave a comment »