HN user
Cofounder at Hunch and Siteadvisor, former MIT CS grad student and undergrad.
Sellers and buyers can now use eBay Authenticate to get independent confirmation that goods are as authentic. It’s starting out just focused on certain types of handbags and luxury items but expected to expand over time. https://www.google.com/amp/s/techcrunch.com/2017/10/16/ebay-...
Consider fashion or home goods. Frequently you see something you like based on pattern, texture etc that cannot be easily described in words. Image search is the perfect fit for these kinds of purchases.
The idea is that you'd probably trust the guy who actually sold 1,000 dresses to Macys more than the guy who just says they're a great dress manufacturer.
Yeah, redis is pretty interesting.
I think we'd have to add some sort of client side caching on top of it so that we're not fetching the same objects over and over. Tend to saturate our network if we don't do that.
The other thing is that I think we'd have to add some sort of object migration so that when redis servers come up or go down we could re-balance where things are stored.
Anything Stonebreaker does is interesting, but I don't know enough about VoltDB to have anything to say. Definitely curious where it goes.
memcached is a poor-man's distributed shared memory system for clusters. We've been layering on top of it to try and fix deficiencies with things like client-side caching, persistence in case memcached drops objects etc.
But I was curious if other people had similar problems and how they were solving them.
In the name of completeness, there are also great packages like OpenMPI and OpenMP.
At least for my particular applications, though, there's either 1) a steep learning curve for programmers 2) language support issues 3) they're designed for batch processing.
Personally, I find shared memory interfaces the easiest to program when there're complicated data access patterns. But that just might be personal preference.
Yeah I didn't mean to sound like that's ALL there is. But I was time and again surprised how often buying decisions had nothing to do with the product, company's need etc. I guess I was perhaps a little naive :)
I vowed after my first startup never again to build an enterprise product for this reason. Plus I don't like golfing and drinking with some random guy in Omaha trying to convince him my product solves one of this top three problems.
Worth checking out pysco as well http://psyco.sourceforge.net/
Though in practice I find that if performance really matters using numpy or writing a C extension module usually works out the best.
Definitely want to second the advice to use EXPLAIN.
MySQL has a lot of very specific limitations about when it will and will not use the available indices. It also matters how you created the indices (one index on multiple columns vs multiple indices on individual columns).
For example, if you created a single index with the columns (date_added, device_id) MySQL would not be able to use the index since device_id is the second part of the index, not the first and thus not available for use in the WHERE clause.
See http://dev.mysql.com/doc/refman/5.1/en/mysql-indexes.html for more limitations.
I guess I just object to paying Wilson $5k to run search-and-replace for me. And I certainly wouldn't trust LegalZoom to actually have documents written by people who understand startups.
And the other sources don't seem to provide offer letters, NDA/invention rights docs, board motions, option grants and all the other boiler plate stuff that's needed.
That all said, I suppose making it too turn-key risks entrepreneurs not really understanding the legal issues involved and getting nasty surprises later on.
someone needs to build a web app that asks a few basic questions, gives you some check boxes to click and then generates all the standard PDFs you need for seed funding, employee agreements, etc.
Points also to the issue that thinking about security from a perimeter point of view (everything outside firewall is bad, everything inside is good) is outdated. There is no inside vs outside anymore.
Yeah, there are definitely Excel models, but personally I find it easier to think Python than Excel. Over time I think there's an interesting opportunity to simulate more what-if scenarios as well and again personal preference is to code in python vs Excel.
Another great education OS is xv6 from MIT
If you're interested in building consumer products, using popular consumer products like Twitter is a must. It's just sort of expected that you have this background when you go talk to other consumer internet people. Plus your products will be better if you're inspired by all the other interesting things other people are already building.
Careful what dictionary you use...my /usr/share/dict/words has things in it that might not be polite/acceptable to suggest.
Unfortunately, academic computer scientists still seem to model their field after the “hard sciences” instead of what they should modeling it after — social sciences like economics or sociology. As a result, computer scientists spend a lot of time dreaming up new programming languages, operating system architectures, and encryption schemes that, for the most part, sadly, nobody will every use.
I think this is a really interesting observation. Many of the interesting things in computers such as advertising bidding systems, social engineering security attacks, social networks, collective knowledge systems, games etc are at the intersection of technology and people.
As someone who is one of those "hardcore eng." types from MIT, one of the biggest differences I noticed between Berkeley/Stanford and MIT was how many Berkeley/Stanford students were actively involved in companies while in school. I think this exposure to industry early on helps students understand that it's not all about the best hardest-core tech. when building great products.
I find that I need transactional databases less and less. Whether I specifically don't need SQL is not clear -- it's a great abstraction for storing and manipulating data.
Specifically, what I loose with transactions is fault tolerance and predictable performance while I find I don't really need atomicity in most places.
Fundamentally fault-tolerance is achieved by having few interdependencies among computer systems. Transactions makes that really hard to do for replicated databases and you need replication to be fault tolerant. So usually people cheat and settle for async replication, but then you really don't have transaction anymore since different parts of your system are seeing different states.
Transactions also lead to difficult to debug blocking behavior either due to deadlocks (btw, where else in computer systems is the advice that you have to destroy all abstraction and understand the entire locking order of your program in one place?) or locks getting held too long due to programming errors etc. I hate when my entire site hangs because a key table has locks on it due to some transaction getting accidentally left open.
Understanding database consistency levels and their nuances is extremely difficult and error prone as well. So you may not really be operating in the pristine transactional environment you thought you were.
Finally, programming to a non-transactional model is actually pretty easy in most cases. You just have to go into your project thinking about this upfront. And the decisions you make building a non-transactional site will probably increase how decoupled all the parts are which will make it scale better anyway.
My personal experience building two startup consumer websites has been that ORMs have been a mistake. Perhaps in enterprise environments where you have a large IT staff and want to isolate DB specifics and the whole data access layer ORMs may make sense. But for a nimble startup with a small number of talented programmers I think ORMs hurt more than they help for a couple of key reasons:
1) performance matters immensely to user experience and I can hand write much better SQL than any ORM I have seen can generate. Additionally I find it easier to predict how well my SQL will perform than to predict how the SQL generated by my ORM will perform.
2) I will likely never switch databases during the lifetime of my company and so switching SQL dialects is not a problem I face.
3) There is an impedance mismatch between tabular data stored in databases and object graphs that most ORMs represent.
4) The specifics of every ORM I've tried always left something to be desired. Hibernate was wicked complicated. Django didn't support multiple databases, SQLAlchemy was error-prone. I'm sure these specifics will get fixed over time, but for me they've just provided further disincentive.