tmcneal

It's hard to get the full context of this presentation just from the slides, but I'm assuming the author is talking about Python test frameworks. I've been using nose in combination with coverage (http://pypi.python.org/pypi/coverage) for a year and have been very happy with it.

It's interesting to see how startups are able to get media coverage without previous connections to tech media outlets.

The OP's approach reminds me of a blog post posted on HN awhile back with some tips for getting press: http://jasonlbaptiste.com/featured-articles/how-i-pitched-te...

Your first sentence is spot on. What I think is getting lost in this conversation is that it makes more sense for retailers to incorporate Facebook-enabled functionality on their own website, rather than have an e-commerce store within Facebook.

I founded a company called Snapline (http://www.getsnapline.com) that helps retailers integrate Facebook functionality into their e-commerce site. We've talked to many retailers, and most are still not sure where Facebook comes into play for their business. Small retailers want to engage and increase their Facebook audience, but it's time-consuming to make consistent feed updates and it's impact on sales is pretty murky. Large retailers seeks to gain much more by engaging their Facebook audience, but implementing features on their site that leverage Facebook data is outside their core area of expertise. I think what can go a long way in solving both problems is incorporating functionality within an e-commerce store that doesn't require a lot of manpower and improves the shopping experience.

If you're using SSL then form data in a POST request will be encrypted. HTTP headers are always encrypted using SSL. What wasn't clear to me from the documentation is whether the 'username' and 'password' are form data, or are actually custom HTTP headers. The latter choice would certainly be a facepalm.

I love seeing these posts every month. They're great inspiration for developers who might be thinking about going off on their own, and a reminder that Rome wasn't built in a day.

Congratulations kreci on reaching your income goal!

In regards to your first bullet, one of Parse's competitors, CloudMine, allows developers to write their own server-side JavaScript code that executes within a sandboxed environment: https://cloudmine.me/developer_zone#code/overview

Along those same lines, I'd bet that the floating section was added to get more eyeballs looking on the right side of the screen where the ads are.

And also: MUDs -> MMORPGs

Do you mean there's a two-click version of the Facebook Like button? Do you have a link to more information about it?

There's third-party vendors that provide an API to verify address information. QAS is one of that's used by some large retail sites: http://www.qas.com/

This is really cool and super simple to install... Nice work!

I can see the value in something like this, especially for more novice web developers who may not know the terms to search for in Google or StackOverflow to find what they need.

I understand it's rough, but here are something of the things I was expecting to see while I was browsing around:

- Some "category" pages, like dbm, are missing definitions. It would be great if definitions were present on every category page.

- I really like that some category pages include a curated list of articles that compare the different options within this class of products. This is exactly what I search for when researching new technologies.

- It'd be nice to have links to the Stackoverflow "tag" page on individual technology pages. For example, the MySQL page could link to this: http://stackoverflow.com/questions/tagged/mysql

I could also see this information being shown in a more visual way. It'd be pretty interesting to allow companies to create an account and build a profile of what their web stack looks like. Maybe something similar to how GuitarGeek.com shows the rigs of famous guitarists? I'd be willing to bet that most web stacks would look more like Eddie Van Halen's setup (http://guitargeek.com/rigview/258/) rather than Angus Young's (http://guitargeek.com/rigview/312/) :)

To be fair CouchDB is very explicit that to get any sort of performance, everything must be a view. "Ad-hoc queries" (i.e. queries that are written on the fly instead of uploaded as a view) are clearly stated as "for development only".

Where CouchDB really falls flat is for write-heavy applications. The default configuration in CouchDB is to not reindex a view until it has been read. When a read occurs, any new data in a view that was added since the last read must be re-indexed by executing the map/reduce functions on that data. If you're writing frequently to CouchDB but not reading a lot (as in a data warehouse) the first query you run is going to be extremely slow, since it will need to run map/reduce on a lot of new data. CouchDB doesn't distribute work to multiple nodes like Hadoop, and I've found even simple reduce functions to slow down re-indexing by a factor of 10. I think CouchDB has settings now to update the index on commit, or you could always run a cron job to regularly query the view and force a reindex, but it's still going to be slow.

BigCouch (https://cloudant.com/#!/solutions/bigcouch) might be a potential choice for data warehousing, since it advertises full compatibility with the CouchDB API but offers distributed map/reduce like Hadoop/Hive/etc. I haven't used it though.

One trend that the author missed is that retailers are starting to use the Facebook Platform to enhance their own retail site. Companies like Amazon, Blue Nile, and Hallmark are using Facebook Connect to provide their customers with more personalized and social features. This approach makes the most sense since it allows retailers to focus their efforts on improving the experience of their own site, rather than investing time and money into a store that exists within the four walls of Facebook and fragments the online shopping experience.

My company Snapline (http://www.getsnapline.com) is helping retailers leverage their shoppers Facebook data to provide a better shopping experience on their retail site through features like personalized product recommendations and gift recommendations. I see these kinds of features becoming much more ubiquitous on retail sites in the next several years.

Justin.tv's strategy of using their video-hosting infrastructure to aggressively pursue verticals within the video watching/sharing/hosting space is working out really well. They seem to have a knack for identifying how people use video and streaming on the web, and are creating products that serve the specific needs of each group.

This paragraph is in dire need of citation:

If your apps have some heavy logging to do, and you can't afford some more expensive setup, then you really should forget about syslog, because normally it doesn't scale well if used with high traffic web applications. It's best used for things like logging done by daemons and system components that do not suffer from the load that a web app with decent traffic can have.

I've seen syslog incite a holy war on HN recently, with one camp espousing that syslog (really rsyslog and syslog-ng) does not scale. As an interested third party, it'd be very helpful to have references to articles or blog posts detailing just how it didn't scale, or at least some first-hand commentary. The article describes an issue with the syslogd daemon in which it grinds to a halt at a mere 10 requests sent amongst 5 concurrent threads. That kind of issue is not going to burn you months down the road when your production deployment refuses to scale. Any stories of the newer open source implementations of syslog failing or severely degrading at production load, or conversely, syslog success stories?

Hi everyone,

I'm the (solo) founder of Snapline, which is a B2B startup that lets online retailers provide their customers with online recommendations via Facebook Connect. Customers who opt into Snapline will see personalized product recommendations based on their Facebook profile; so it looks at age, gender, location, education status, interests -- as well as view and purchase history -- to determine the best products to display.

I definitely appreciate any feedback you may have, and am happy to answer any questions!

The site renders extremely slowly in Safari 5 on my MacBook Pro; especially the autoscroll.

Just some constructive criticism but... everything looked like an ad to me. Each item looks very similar to an AdSense text advertisement, so at first glance the site appears to be a link farm. It was only after hovering over the links did I realize these were in fact not ads.

The fact that CouchDB is written in Erlang is only part of the equation.

You're not considering that CouchDB views are written in Javascript or that CouchDB uses HTTP as its connection protocol, which has more overhead than the typical binary protocol of traditional DBMSes.

Also, avg. response time in CouchDB is directly proportional to the number of view invalidations that occur. If your data is changing a lot your views will be invalidated frequently and for those requests avg response time will drop significantly. Throw in a reduce function and re-indexing can become an order of magnitude (or more) slower.

Yes, but are these people friends/family/colleagues, or actual stakeholders or potential users? Obviously more weight should be given to the later.

Having a de-normalized, document-based / column-based / whatever-based NoSQL database doesn't mean that every query or map-reduce function you write in it is going to be super-fast.

I think we all could benefit from articles similar to this one but applied to NoSQL databases: Take a real-world example of a slow-query in a NoSQL database, show how you identified it and profiled it, show how you solved it.

I've personally been burned with performance issues in CouchDB when it came time to perf-test my queries, and I really would have benefitted from articles that detailed a real-world example like this.

I feel like there's a lot of tutorials on how to create toy applications using NoSQL, and a lot of claims on how things like sharding and mapreduce will let you scale to the moon, but comparatively little information on how to do real-world things like what this article covers.

Yeah I had a column for comments too, I just didn't paste that column into the google spreadsheet.

I created a list two years ago when I was promoting my mobile app. Here it is as a Google Spreadsheet:

https://spreadsheets.google.com/ccc?key=0AqvAQlclIWYPdExaNll...

I really enjoyed the writing style of this post.

err.. other than perhaps jQuery, I don't see how any of your examples refute what the OP is stating. To stay current with modern web development (such as the technologies you listed), developers need to continually improve the breadth and depth of their knowledge.

Before viewing the article I thought this was referring to the iPhone App: http://itunes.apple.com/us/app/epicwin/id372927221?mt=8

Isn't the value of the API in the data you're retrieving, not the design or feature-functions of the API?

I'd think that your choice of integration between Facebook or LinkedIn (or both) would be based on your intended audience.

Interesting perspective, but I'm surprised that you're lumping in "controller level" tests (i.e. unit tests) with tests against the view.

While I'm definitely on board that tests against the UI are brittle, I feel like unit testing individual methods and classes ensure your code is modular and functions as designed.

Integration tests are great, especially since they more reflect how a user interacts with the code, but I think you can get a lot of value from unit tests without getting too religous about it.

FYI, Octopart recently announced that they are indexing Digikey products. See relevant blog post: http://octopart.com/blog/archives/2011/1/digi%252Dkey-produc...