archive-fm.com » FM » G » GREER.FM

Total: 127

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Geoff's site: An Office Made of Software
    didn t make sense right I must digress a little to address this point Many organizations make incredibly bad decisions Individuals in organizations often have poor incentives Most importantly people get fired for screwing up This causes organizations to be overly risk averse Nobody ever got fired for buying IBM equipment is the stereotype of this behavior Since workers are incentivized to not make mistakes they often avoid risks and copy the decisions of people in similar situations Everyone else is doing X We should do X This is usually a reasonable heuristic If everyone else jumps off a bridge you probably should too Most of the time these decisions aren t even explicit Of course you re going to have an office How else would people work together Companies have had offices for centuries When would it ever make sense to change that It s often wise to re evaluate these implicit decisions because sometimes they no longer make sense Offices are a good idea for many jobs today but there is one specific case where I think they re no longer beneficial software companies What do programmers do all day They read code They write code They read docs They hopefully write docs They communicate with coworkers through IRC e mail instant messenger phone calls ugh group meetings and face to face interactions In short programmers are either writing code or communicating with each other At no point are they shaping matter Communication across the globe can be practically instantaneous so there s no fundamental reason why software has to be written in a single location Microphones and cameras are cheap and integrated into most computers so any disadvantage of remote working is a software problem Offices hinder software companies in many ways They limit companies to nearby

    Original URL path: http://geoff.greer.fm/2013/08/28/an-office-made-of-software/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: Floobits Update: 10 Months Later
    I planned on getting rejected Matt and I spent a couple of days preparing for the interview We knew we weren t good at selling stuff so we focused on having a great demo To make sure there were no problems with network access I ran a local instance of Floobits and connected our laptops with an ethernet cable I felt a little silly walking into the interview room with two laptops connected by a wire Other candidates were working on all kinds of cool new mobile wireless things Meanwhile we were using a copper conductor to demo plugins for text editors that were created a quarter century ago A few minutes before the interview I thought How did I delude myself into thinking this idea could work The interview went by absurdly quickly We answered questions to varying degrees of satisfaction Our demo went well We drove back to San Francisco in rush hour traffic and discussed our chances I put our odds at 50 Right after I walked into my apartment I got the phone call We celebrated that evening by going to Zeke s We started with beer but the night ended with shots of tequila Since then Matt and I have spent almost every day writing code talking to users and exercising About a month ago we turned on billing In the last two weeks we started publicizing ourselves First we showed Hacker News The reaction was unexpectedly positive Our poor Node js server died under the immense load This week we launched on TechCrunch And of course Y Combinator posted about us Since the TechCrunch launch we ve grown mainly through word of mouth Apparently Floobits is useful enough that people tell their friends about it Some of them even pay money This journey has

    Original URL path: http://geoff.greer.fm/2013/08/01/floobits-update-10-months-later/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: Busy
    I ve been writing code every day for the past 6 months Actually that s not quite true One day I only committed some JSLint and whitespace fixes I did spend that day working just not on code I m spending a lot of time pair programming with my co founder Matt so not all of those commits are mine Still I ve never before worked as hard as I

    Original URL path: http://geoff.greer.fm/2013/07/11/busy/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: Random CSS Stupidity
    it unlikely that browsers would implement arbitrary precision decimal arithmetic for styling calculations so I was curious to see how close I could set the padding to zero before browsers rounded down Assuming you have JavaScript enabled you ll know the answer for your own browser below I am an orange div with margin 10px 0px My parent div is blue It has padding 0px 10px I am an orange div with margin 10px 0px My parent div is blue It has padding 1px 10px JS hasn t run yet Do you have JavaScript disabled Use Web Inspector or Firebug or whatever to verify my claims You ll notice the top blue box s padding is close to zero but not quite The bottom box s padding is slightly larger putting it over the threshold and not collapsing the child s margins The exact padding depends on your browser Chrome s Planck length is 1 64th of a pixel The reason for this is explained on Webkit s LayoutUnit page Firefox uses about 1 120th of a pixel but I have no idea why Safari doesn t care about anything less than 0 99 pixels This seems fitting for a

    Original URL path: http://geoff.greer.fm/2013/03/10/random-css-stupidity/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: The Cost of Features
    use of complex cache hierarchies indexes and efficient data structures requires more code Making software reliable distributed and scalable takes boatloads of code Until recently rounded corners on a web page required comical amounts of code So we have some good reasons for adding code but that s not enough to cause software bloat We could prevent bloat by removing about as much code as we add over time Why don t we do that Several reasons come to mind It can break dependent software While the feature on the chopping block may not be popular with users other popular software might be dependent on it Disgruntled users Removing a feature used by only 1 of users guarantees a deluge of hate mail 10 000 users means 100 angry emails At the same time it causes the other 99 to wonder if their pet feature is next Removing things isn t fun If your code is clean it s trivial and boring If your code is ugly it s a giant pain Either way building something new is more enjoyable It doesn t impress colleagues I removed some old code is rarely said with pride in a stand up People don t brag about removing features or old code So removing code is a tough bullet to bite But then how do we stop software projects from collapsing under their own weight The best answer I can come up with is You can t The battle is lost as soon as you type git init Why Again we can look to cars Car companies have massive budgets for designing cars but they don t reduce weight They have a different strategy as a model increases in weight capabilities and price manufacturers introduce a smaller model The Honda Civic used to

    Original URL path: http://geoff.greer.fm/2013/03/06/the-cost-of-features/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: Cross-editor Real-time Collaboration
    Developers spend years learning and customizing their editors They hardly ever switch because doing so means they lose all those customizations Worse the experience and knowledge of their old editor becomes useless These high costs of switching are why developers usually end up choosing an extensible maintained popular editor and sticking with it for their careers In addition to that deal breaker web based editors have a bunch of minor annoyances They require a stable Internet connection If they go down you can t edit things They usually have no plugin architecture Even if they do the ecosystem of plugins is tiny It s hard to integrate them with local programs like linters or code searching tools Revision control integration is also a problem How do you commit and push from a web based editor give them your private key Finally there s the risk that the company making the editor goes out of business Unless the company has a responsible sunset pledge every user is SOL They ll have to find something else and pay the cost of switching editors all over again Despite all these disadvantages web based collaborative editors thrive What gives I think there s a much better solution to real time collaboration and I m going to make it The plan is to build plugins for every popular editor Then Alice can work in Vim while Bob works in Emacs and Carol edits in Sublime Text 2 Everybody s happy Of course there will be a web based editor too Nobody has done this before and I m pretty sure I know why It s a huge pain to make this Not only do you have to solve all the problems of a real time collaborative editor you have to write plugins for every popular

    Original URL path: http://geoff.greer.fm/2012/10/19/cross-editor-real-time-collaboration/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: A Responsible Product Sunset Pledge
    Slicehost Sparrow Just look at Google and Facebook s acquisitions These are successful acquisitions but the percentage of dead products is startlingly high This problem doesn t just affect the customers of these products it poisons the well for all startups It s hard to get off the ground if people are worried your company will die It s harder still if they re also worried you ll leave them out to dry after acquisition Because of this I d like to suggest that startups have a responsible product sunset pledge Here are some guidelines If acquired keep everything running for a while For most products a year makes sense Give plenty of notice before shutting things down 6 months seems reasonable Make it possible for anyone to run a fully featured instance of the product This means releasing the source code and documenting how to set up and run your product I realize startup code and architectures are seldom clean but you should work to make set up reasonably painless Liberate customers data Build export APIs and scripts to consume them Pledge to do these things and you ll probably help your own business If enough companies have pledges

    Original URL path: http://geoff.greer.fm/2012/09/19/a-responsible-product-sunset-pledge/ (2016-02-15)
    Open archived version from archive

  • Geoff's site: The Silver Searcher: Adding Pthreads
    queue At the same time worker threads grabbed paths off the queue and called search file on them I had to use a couple of mutexes to avoid some race conditions but it was surprisingly easy to get correct behavior Once I was ready I re ran my benchmark time ag blahblahblah code ag blahblahblah code 1 47s user 2 54s system 231 cpu 1 731 total Much better but it was only 0 3 seconds faster than non threaded Ag Searching files is embarrassingly parallel I expected more than a 15 performance improvement So I started tweaking things Most changes didn t help but performance was significantly affected by the number of worker threads I assumed 3 4 workers would be ideal but I ran benchmarks with up to 32 threads just to make sure I graphed the results For comparison non threaded Ag takes 2 0 seconds on my MacBook Air and 2 2 seconds on my Ubuntu server There are a couple of takeaways from this graph First OS X sucks at this benchmark With 16 workers performance is pitiful I had to remove the 32 worker results from the graph as they made it hard to see the difference in performance with fewer threads Searching with 32 workers took 8 5 seconds on OS X That s just shameful On the other hand the Linux kernel seems to get things right Even with 32 workers it took 2 2 seconds Again I pulled out the profiler With 32 workers Ag looks like this on OS X There s definitely some silliness going on in the kernel Anyway getting back to the graph up above The second thing I learned was that the optimal number of worker threads doesn t correlate with CPU cores Even on a

    Original URL path: http://geoff.greer.fm/2012/09/07/the-silver-searcher-adding-pthreads/ (2016-02-15)
    Open archived version from archive