amirathi

> thus making the diffs sane

You can also use ReviewNB [1] that is literally built for Jupyter notebook diffs. You can see notebook visual diffs for any commit or pull request on GitHub. For pull requests, you can also write comments on a notebook cell (emulating the typical code review experience for Jupyter notebooks)

Disclaimer: I built ReviewNB for Jupyter notebook code reviews on GitHub.

[1] https://www.reviewnb.com/

> don’t play well with git

I agree, and this is why I built -

- ReviewNB - Code review tool for Jupyter notebooks(think rich diffs and commenting on notebook cells)

- GitPlus - A JupyterLab extension to push commits & create GitHub pull requests from JupyterLab.

[1] https://www.reviewnb.com/

[2] https://github.com/ReviewNB/jupyterlab-gitplus

GitHub is having major availability issues these past couple of months. 4 incidents in Feb, 4 in March and 2 in April so far.

Source: https://www.githubstatus.com/history

I look forward to reading root cause analysis promised by Nat in Feb: https://twitter.com/natfriedman/status/1233079491204804608

Great advice if you absolutely want that ONE job at this ONE company. If you are in that boat then it's probably worth it to spend ~10 hours creating something valuable to offer.

Most people generally have a set of companies that are ideal for them in a tier'ed manner. In that case, more efficient way would be to choose ~5 companies, do a lot of homework about their business & write to key people at these places telling in ONE paragraph what you can do for their business. If it fails, choose next ~5 and so on.

It falls somewhere in-between spending 10 hours of effort on 1 application & mass applying to 50 companies without any effort whatsoever. This is also how effective sales teams work.

Focusmate

Duplicate of: https://news.ycombinator.com/item?id=22644096

API Gateway + Lambda + RDS?

Congrats on shipping!

I played with the demo & liked the capability of quickly inserting a snippet of code by selecting + customising a widget. The idea of making it quickly shareable / deployable apps is also very powerful. You product is along the lines of Streamlit / Voila / Plotly dash. Write plain python to make deployable front end apps for dashboarding etc (additionally you help writing that python with readymade snippets).

While the capability is powerful, I'd recommend finding a persona that would actually use it enough to pay for the "pro" version. Currently it's geared towards data scientist, but they are very comfortable writing notebook code to generate visualizations. So the low-code (generate code from widget) part is not very appealing to them. They need simple yet powerful python constructs that creates beautiful front end components for them (headers, paginated tables, plots, graphs, interactive widgets). And then make it easy to deploy these apps internally. Checkout Streamlit that promises to do both these very well.

Deliverability is a big marketing/selling point for all these providers & important selection criteria for their customers. So it'd be very interesting to see what % of emails for each provider landed in Inbox vs Promotions/Spam/Junk folder.

Elastic Beanstalk with Docker has worked well for me.

If you docker'ize the app you can really run it anywhere.

Checkout treon[1], open source testing framework for Jupyter notebooks. Since it runs via CLI you can hook it up to any CI platform of your choice.

Disclaimer: I wrote large part of treon.

[1] https://github.com/reviewNB/treon

> The only build-in problem with Jupyter Notebooks is JSON, mixing input and output (and making it pain to work with version control)

Absolutely. JSON notebook format makes it very hard to do code reviews, merge in remote changes etc. After being frustrated with lack of solutions, I built ReviewNB[1] specifically to do notebook code reviews on GitHub. Alternatively, Nbdime[2] is also a nice open source library to see diffs locally & merge in changes.

[1] https://www.reviewnb.com/

[2] https://github.com/jupyter/nbdime

I agree with everything except,

> Don’t add a co-founder after the fact

Late co-founder makes a lot of practical sense to me.

- It's less risky for the incoming person to join a small profitable company instead of joining an idea

- You broadly know the problem space you will be working in (market, customers etc.) and the vision/direction of the company. Less likely to have fallouts a year or two down the line

- More informed equity negotiation than just splitting it equally

> I highly doubt mu abilities now and actually thinking of quitting

Absolutely do not quit. You'd be amazed at how fast you become "better" when surrounded by phenomenal teammates. Finding a team where you are in awe of people around you is rare (even at FAANGs). Please do not squander it by quitting. Just keep doing code reviews, design discussion & you'll quickly level up (6 months to a year tops). Good luck!

I am using Webflow and highly recommend it.

After going through a lot of marketing fluff, I landed on this useful page which explains Metaflow basics: https://docs.metaflow.org/metaflow/basics

Here's my understanding:

- It's a python library for creating & executing DAGs

- Each node is a processing step & the results are stored after each step so you can restart failed workflows from where it failed

- Tight integration with AWS ECS to run the whole DAG on cloud

I don't know why their .org site oddly feels like a paid SaaS tool. Anyway, thank you Netflix for open sourcing Metaflow.

A year ago, I was frustrated (and surprised) to see one can't do code reviews with Jupyter Notebooks. GitHub diffs for notebooks JSON are super messy.

I set out to build ReviewNB[1], code review tool for Jupyter Notebooks. Turns out a lot of other people had this exact problem. One can see visual diffs & write review comments on notebook cell. Currently only works with GitHub though.

If you want to diff locally (before committing changes), you might like nbdime[2].

[1] https://www.reviewnb.com/

[2] https://github.com/jupyter/nbdime

As a small company you can offer flexibility, growth, and learning along with a competitive pay.

Flexibility - Work remotely, set your own hours etc. We care about output/productivity & not how or when you work.

Growth - Make sure there's always a next level/challenge/goal/increased pay etc.

Learning - In small companies folks can (and should) wear different hats & get to learn about sales, business, marketing etc. on the job.

I'd look at SO Developer survey & focus on things that matter to people apart from company vision & pay.

I was in the same boat as you a year ago (solo developer building reviewnb.com). I wrote API tests for the backend (assert API x with y input returns z) and completely forgo any unit tests. This has given me 80% benefit with 20% effort.

I wrote these tests after launching the product publicly and just before support requests / bug fixing period started with the simple aim of avoiding regressions as I work through the improvements.

If I were to give general suggestions on the topic,

- In most cases having high level sanity tests is low effort high value decision.

- To write tests or not shouldn't be a binary decision. E.g. If you think a specific aspect is going to need refinement work then tests for those modules can help you immensely.

- Going for high % coverage very early on for the sake of mental satisfaction or bragging rights is usually not a good time investment

My only regret is not having any automated tests for frontend. Investing in some basic selenium tests after launch would have been worth it.

"The well grounded Rubyist" is a fantastic book to learn Ruby. Right balance of theory and practice. Easy to read and still offers a lot of depth about the internals of Ruby.

Python + Django on AWS Beanstalk backed by Postgres on RDS.

Django REST Framework provides pretty much everything you need for a REST api.

It's astonishing how many developers resign to the idea that "estimating software projects is impossible". It's impossible when there are either,

- Technical uncertainties (e.g. self driving cars)

- Human uncertainties (multiple different teams building single large software system)

- Scope uncertainties (we don't know what we are actually building until we get into the weeds)

Outside of these we should be able to make reasonably accurate (+/- 30%) estimates. I wrote a blog [1] about it if someone is interested but here are the main takeaways,

- Don't just estimate writing code but also include time required for testing, documentation, communication, setting up infra/deployment

- If certain part is hazy ("is there a reliable python library for speech to text") then research it enough to know the path ahead

- Breakdown the system into smaller units until you feel confident to estimate each piece

[1] https://blog.amirathi.com/2018/02/05/science-of-software-est...

In that case, I would frame the conversation as a problem solving session. You can do the legwork of customer inputs, cross team talk, management buy-in etc. And once you zero in on the problem (and have it prioritised) just talk to engineer and together brainstorm the ways to solve it.

Best thing you can do is to bring customer problems to engineers & come up with solutions together. Far too many PMs create detailed spec documents (solutions) on their own and throw it over the wall to engineers.

Benefits of this approach,

1. Engineers get to know more about the customers & their pain points first hand.

2. Engineers are bought into the solution as they co-created it.

3. You usually come up with better solutions as both business and technical constraints are all on the table.

-cloud storage

-data costs (cell phone, broadband)

-hosting (became free in last couple of years thanks to Netlify, GH pages etc.)

Their turbo plan is $5 per month for unlimited sessions. Their free plan gives you 3 free sessions a week.

It's a bit weird that as a signed up user I can see the pricing information but it's not publicly available on their homepage. Anyway I like the service as 1 or 2 sessions in a day helps me get into the rhythm.

When someone detects a bug with smallest possible fix (e.g. typo) how long does it typically take from detection until all your users are able to see/receive the fix.

Introduction to Algorithms by Cormen et al.

Yes.

With 50-company approach you increase the absolute number of first callbacks you get (hence everyone thinks it's optimal). With 5-company approach you increase the odds of actually getting through to a single job offer. Think about it.

I'd say market salary + as much equity as you can negotiate between 0.4 to 4%.

Disclaimer: I prefer to be pessimistic about startup equity for employees. It's like buying a lottery ticket where folks running it dictate the odds & have legal mechanisms in place to change the prize money at the very end.