4,443 karma · joined October 20, 2010
kishore at typesense org https://calendly.com/kishorenc/30min
Edit: grammar
2. Failure is the default state of any venture. Give your best to succeed, but remember that you're starting from failure. This way, you learn to handle the lows associated with failures better.
3. Focus on the process as much as on the results. The idea is to master the process that's expected to return results so that you can keep using it to succeed at various things.
1. Pick a problem that you're passionate about and try to solve it in a better way. 2. Give it to a few people, ask them to tell you how to make it better. 3. Go back to step 1
Development isn't an end in itself. There are only so many books you can read - the real learning comes when you refer to a book/resource while you're trying product something tangible.
Lucene is one of those projects which hardly has any real competition. That's surprising given how many real world software projects have a search requirement. While Lucene is excellent, it's not without flaws and competition is always great.
The point being - Microsoft's biggest headache is catching up with AWS on the tooling and documentation. They seem to be going all out in competing with every vertical that AWS has, but that might not be the best approach as they might endup spreading themselves too thin.
Edit: Clarify about type system.
The 32-bit trial version of kdb+ is available for non-commercial use [1], so I went and downloaded it. The linux zip download is 278KB. Uh ok! I was expecting it to download more stuff (much like Chrome's installation), but nope, that's all there is to it!
Picking a practical "project" will help you stay motivated in learning things and you will also have the benefit of "publishing" it as something you "shipped".
Once you start feeling a little confident about the code you write, start putting your projects up on github. Also, start contributing to other projects in github (e.g. libraries you have used in your own project). There are many projects where you can easily begin by fixing small bugs. Then you can slowly learn the code base enough to contribute features.
Some will suggest software consulting, but there is a lot of things to manage there unless you're familiar with how the consulting world operates already and you've done it in the past. You will have to spend a lot of time setting up schedules, deadlines, prospecting for new customers etc.
Example of big data could involve transactions, logs, click stream, sales data, or even GPS data (say in telecom).
If you're looking for some opportunities here, a good safe bet would be Hadoop and HBase. You can treat them as open source implementations of the original Google papers on Map Reduce and Big Table respectively.
Today so many companies are realizing that they have data locked up in logs and other largely static databases that they can analyze using map reduce jobs. You can generate reports, trends, patterns and more from these analysis and can use them to guide business decisions.
If you grow to be more than 2-people, then taking a mirror dump of the prod db to run queries against is pretty trivial effort.
You should check out Google's research papers [2] - they have some good papers on various topics and are very practical.
[1]: https://ramcloud.stanford.edu/wiki/download/attachments/1137...
Not the OP, but don't take it personally. When someone's building a side project, there are so many things to do, and making using of an existing authentication system is fairly reasonable in the interests of time and effort vs value.
Of course, you have a right to your privacy, but you don't need to be so rude.
* offer levels of support along with the pricing tiers - larger companies sometimes require SLAs that require having someone they can call up if something goes wrong. You can charge for this.
* charge based on number of users - bigger companies have more users
It's difficult to arrive at a price point that works for both small and large companies. You need to choose whether you want more customers who pay less or fewer customers who want to pay more. It will boil down to how high-touch your sales process is. People aren't going to order a 5-digit service online in a low touch sales model.
Some business I know start-off with a low touch model (primarily because hiring full-time sales folk(s) is expensive) and then gradually raise their rates and go high-touch.
Keeping that aside for a moment, even though GPUs are the rage these days, it's not very easy to integrate with them. For e.g. language binding. You also need to model your program in a way that optimizes for GPU-based processing.
One of the reasons why the migration worked for us was that one can (with a bit of discipline) get into idiomatic Scala slowly. You can definitely start off writing Java-ish Scala and still gain a lot from the decreased verbosity and nicer APIs. You can safely stay away from over-using implicits, functional programming etc. till you get a good grasp of the language. With excellent Java interoperability, you don't have to convert your entire stack to Scala overnight, but slowly replace old code with Scala.
With respect to performance, if you insist on writing idiomatic Scala, there is definitely a performance overhead, because the JVM is not suited for large amounts of small allocations, as is often the case with an immutable style of programming. However, we run a pretty large scale data crunching system, and depending on what your code does, CPU bound performance hit pales in comparison to the network and I/O waits, so for us, it was not a big deal. When we absolutely needed to optimize a tight loop or something, we wrote C-like Scala, using while loops and mutable data structures.
Addendum: The greatest win for us was the readability of the code base. Scala allows you to largely keep your data structures immutable, so it's much easier to reason about. With parallel collections, Actors and Futures, concurrency support is excellent as well. You definitely need to pick up a few new concepts, but the time is well spent as once you get a hang of those things, your productivity will be 10x - you don't have to wrangle with primitive concurrency constructs.
Yup, plain english which is pretty loaded in the favor of subscription. Point me to one heading which says "VIP subscription costs only 39 USD per month".
every retailer has to optimize their site to perform
This is not the same thing. The typical shopping site constitutes of 1 time purchases. When I google for a product and end up on your site and try to purchase something, I am not going to think it's a crazy thing like monthly subscription whether I buy something or not. Given this scenario, choosing a default like that is not simply optimizing.
We can argue over the fine details, but you can't convince me that this is not shady.
The "checkout as a regular member" is in a small font on the sidebar, while the main CTA is big, bold and defaults to the VIP program.
The part where you're told about the monthly fee is in the last sentence of the sidebar. I had to practically hunt it to find it - for most people shopping online this will be oblivious.
By giving the screenshot - atleast to me, you have proved without doubt that the site is indeed misleading.
[Edit: grammar]