vpj

Client library (GitHub): https://github.com/lab-ml/labml

App (Github): https://github.com/lab-ml/app

Sample: https://web.lab-ml.com/run?run_uuid=d4722546f58411ea8addd3f9...

https://github.com/lab-ml/poker

>>> That won’t work for our auto parts suppliers, so, no, our US factory can’t stay open

Remote: Yes (Part-time preferred)

Willing to relocate: May be

Technologies: Deep Learning

Résumé/CV: https://www.linkedin.com/in/vpjayasiri/

Email: v p j a y a s i r I [a t] g m a i l . c o m

Spent around 8 months full time learning machine learning. Worked mostly on reinforcement learning projects for games.

This was the tweet (April 2018) Elon has replied to.

http://vpj.github.io/b2b_customer.html

tl;dr; We got the contact from one of our investors. First meeting was a product demo and a short presentation. There were long time gaps between meetings (it took several months to get to the trial). We didn't have a simpler way of doing the trial.

https://github.com/vpj/docscript

Will add a command line compiler and stuff soon. We are using it to generate documents at our startup. So it will be in active development for sometime.

http://vpj.github.io/docscript/

Author: https://twitter.com/aprilzero

Here is how I use it in such scenarios:

  elems = {}

  Weya elem: document.body, ->
   for k, v of data
    elems[k] = @div "#{v}"

  #when element k changes
  onChange = (k) ->
   elems[k].textContent = "#{data[k]}"

http://www.perceptualedge.com/

I've read books by both these authors and they were very good. Their websites cover most of the important content found in the books.

http://blog.bissantz.com/images/2008/01/tod_der_businessgraf...

I wonder why they add the table grid at the end. A grid could have been useful if there were a lot of columns, but certainly not in this case.

This is a similar idea I was working on http://vpj.svbtle.com/variable-length-underlining-to-help-se...

The problem was when it started giving trouble even before 10K records, and not even more than 60 requests per second, which even a very low resource PC would handle without a problem since it won't even take a few milliseconds to compute (probably even without an index, just a sequential search). And we had to make changes to fix this.

It went on and on; every few weeks, users and content would grow and our app would fail. We didn't want to move away; just like you said, we thought the solution wasn't to avoid it, but to solve it.

Finally, after changing/improving the design a number of times, we considered using app engine backends to do central stuff such as maintaining the main index. At the same time, looking back at what we've been doing so far, it was quite clear that we were spending our time, which for sure we should have spent on building something that adds value to users, on learning some platform and trying to alter our architecture to fit into it. And we were going deeper and deeper in the hole, and we knew it would be hard to move.

Our vision is simple, and it has nothing to do with picking up some technology and figuring out how to make use of it. Instead, we try to start from the customer and work backwards. While on app engine, we once stopped taking new low paying customers (listings), until we fixed issues - I think this was a terrible.

Decision of moving away from app engine wasn't easy. We had to literally rewrite everything, and the fear of similar problems coming up was there.

Also, I never recommended anyone not to use it, I was just telling our story. In fact, I still use app engine for some work, and we would switch back to app engine if we are convinced that it's the way to give a better user experience.

About data store being slow, they charge us per data store read. It slowing down as the number of reads increase, for me, sounds like saying it's your fault if your calls drop because you are making a lot of calls.

About search API, we didn't use it for auto completion; we maintain a small dictionary for that.

Just to clarify we were building the index at the start up.

About scaling, we have given some thought to it. But not so much since it's not something we will require in the near future. We can create multiple instances and balance the load as long as the index is small enough to fit in memory.

I'm sure there is a way to get this working on app engine. But we are glad that we moved, and it runs smoothly. And more importantly, we have been able to give the users a lot more benefits during the past couple of months than during an year on app engine, because we had more time to focus on users. And if we had moved earlier, we would have been able to do more.

I use C and Coffeescript.