Hacker Newsnew | past | comments | ask | show | jobs | submit | chriskottom's commentslogin

It would be worth spending 10 minutes to write up some quick copy to that effect. When I entered my URL, I felt like it went into a black hole as there was no mention of "what happens now".


Thanks for the input. Yea, I plan on starting to clean up the flow of everything.


During all the months of work on this, at what point did someone tell you, "I've been looking for something exactly like this."

At the risk of straining the analogy, the pizza might be tasty, and the box might be attractive and functional, but if a pizza delivery guy showed up at your door unexpected and unannounced, would you just pay him, or would you be more likely to say, "I didn't order this."


I wouldn't claim to be any kind of expert, but the advice you need to hear right now is: start. Write about what matters to you. Don't wait to come up with a coherent thesis or mission statement about what your blog is before you've written the first post. If you start writing regularly, you'll find what you care abut and what resonates with others, and that's the sweet spot where an audience can potentially be found.


  88,846  PHP
   1,420  HTML+ERB
   1,177  JavaScript
   1,128  HTML
     423  Ruby
     250  XML
     160  Markdown
     117  Emacs Lisp
      91  INI
      65  Perl


Not actually so surprising considering `$_GET` is a PHP superglobal.


Though I'm surprised how many aren't PHP, for example all the Ruby repos...

Edit: ah, most of those are Metasploit scripts.


try "exec params" and "call request" for shooting your foot in other languages


The article had a few good insights in the first few paragraphs about the problems they were looking to solve: "pogosticking", structuring of search results, steering users toward the features that their data showed mattered most, etc.


Such timesink.


So lost hours. Many unproductive.


There are two approaches that I would consider. The first is simply to ask: does your development work absolutely require large test data, or might it be possible to reduce the size through more precise selection? And more to the point, if such is possible, is it possible with a reasonable amount of effort? This is such a common problem that my guess is you're not the only one trying to solve it.

If the size of the data set is essential to your development, then could you set up a development database server on dedicated machine (could be an old workstation/laptop) on the local network that could act as common infrastructure for the whole team? This would only work if your application supports connection to a remote database, but it would solve the problem of externalizing the need for a database and sharing that resource among your development team rather than having each of you running a big DB locally.


Most long-term predictions tend to be made by people living in pockets where the future has already arrived, but it seems appropriate to recall Gibson's prediction about uneven future distribution. Trying to extrapolate based on local maxima will always produce a trendline that outpaces reality. To his credit, I don't see any flying cars here; the author bases many of his predictions on innovations and trends that are already to some extent or other in progress. But in order to bring a change from possible to widespread, it has to be commercialized first, and I struggle to see a profit motive for some of these things, even in the next 30 years - i.e. energy consumption monitoring by Google when electricity is cheap thanks to nuclear fission, etc.


Very insightful! Thanks for mentioning: Gibson and local maxima. I completely agree with your view on commercialization; in terms of monitoring consumption: I think there will be money in analytics/data that help us push forward ubiquitous computing (even if electricity is cheap)


Seems like a weird strategy. I admire the focus shown, but what if Thomas Edison had decided after 10 years to rebrand GE as Something Something Light Bulbs, Inc?


If all they were making would be light bulbs, why not? RIM rebranded to BlackBerry (though RIP may have been a better choice :( ).


The article isn't clear on it, but there have been studies (http://baymard.com/blog/making-a-slow-site-appear-fast) that show the perception of fast loading is actually more important than the real thing. Showing the user a "Loading..." graphic is the most common manifestation of this, but there are others. (Unfortunately, the original Forrester-Akamai study seems to be unavailable.)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: