I can’t boil it down to 3 because there are many things you need to understand, some details can be gleaned via observation too.
So some of the top questions you should ask IMO are below:
When was the last raise, what was the amount and time to raise it? What is the makeup of the investors (Angel vs. VC etc)?
What is the next milestone on the fundraising side?
What is the biggest competitive advantage/product feature the company has?
What are the biggest issues facing product/development?
How do you see my role in helping the company?
How can I best help the company if I come aboard?
What is the biggest opportunity you feel the company has?
What is the biggest risk the company faces?
Who do I report to? – this trips some startups up but can highlight potential issues.
How many employees are there today? How many do you plan to hire in the next 3, 6, 12 months? How many employees have left since founding?
Equity and the vesting schedule details. Share class information as well. Current dilution, outstanding shares issued and reserved is nice to know too as well.
For what it is worth and this applies to any size company, not just startups, you should also ask about what agreements they want you to sign and get them as early into the process as possible without being unreasonable. e.g. outside work policy, NDA, non-compete, non-solicitation, compensation, equity, etc. Some of these they may not give you until you agree at least conditionally verbally, but there should be no reason you can’t see them once you do. Companies that hide these until your first day make me nervous, at the same time that doesn’t mean they are bad, just maybe been given bad advice or have a lack of understanding themselves.
This entire thread is gold. This is a direct rip off from the top most comment. Bookmarking it here for reference.
Prosemirror is an incredibly well-written rich text library. But, lacks proper prose on how to set it up in a project for beginner / occasional JS developers. By the time you’ve finished reading this you’d learn:
+ How to install prosemirror into your JS codebase (that isn't using fancy modern tools like Webpack, Babel, etc currently). + Why the installation is difficult. + Some modern JS practices.
The conventional way of using an external library was to include the JS file in your index.html in a script tag. This will attach a global namespace/variable for that library which will expose the library’s APIs and methods.
You’ll include <script src=”jquery.js”> in your index.html
After that you’ll access all jQuery APIs via
Good News: Things have changed now. Most libraries are now written as ES6/CommonJS Modules which means your global namespace remains pristine.
Bad News: Things have changed now. There are extra steps that you’d need to make before incorporating these libraries into your JS code.
I’m assuming you are either familiar with ES5 JS and / or have a legacy JS codebase. To use Prosemirror in your codebase, you’d have to find a way to export necessary Prosemirror APIs into the global namespace.
Basically, build a ProseMirror.js file that you can use like jquery.js
Create a folder & file structure as below:
1 2 3 4 5 6 7
Put the below content into package.json
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
The package.json file declares all the dependencies to build a final
ProseMirror.js file, including all the tools needed.
Now it’s time to use this
package.json and install the dependencies. Run:
After the dependencies are installed, create a
rollup.config.js file in the prosemirror directory and put below code in it.
This tells Rollup to take our src file from
src/index.js and spit out a
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
The configuration is mostly self-explanatory. We are telling Rollup to first convert all fancy ES6 code to ES5, then resolve all dependency libraries from
node_modules folder and spit out a final
ProseMirror.js as a self executing module format.
Now’s the most important step – Writing the code to import all ProseMirror APIs and exporting them to
Put below code into
1 2 3 4 5
Without Rollup we would have had to manually attach each API to window ourselves. Like:
But luckily we have a better way. Rollup can just parse this file and do that work us. Just run:
You will see a
ProseMirror.js file being created at
All that is left is to use this compiled JS and initialize a ProseMirror editable area.
We’ll include this js file in
public/index.html and test out a small demo.
Put the below code in
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
index.html in a browser and you should see a nice little rich text editor out there!
However convenient this seems, this is a non-scalable way of using ProseMirror. For example anytime you want to use another API from ProseMirror, you’d have to edit
src/index.jsto export that API for you. Also, polluting the global namespace is a thing of the past. Moving your project to a good module system (like ES6 Modules) would be more beneficial than the cost involved.
The default way of serving static files like JS & CSS via Spring Boot is to put your static folder under /src/main/resources/public. The Internet will give you all kinds of variations of this solution, but almost all of the solutions have a problem.
The static files will be bundled up into the JAR file (that is if you are using the embedded server that comes with Spring). This means you have to reboot the JAR / application everytime you change your CSS or JS. Things could get really painful when you already have a webpack compile process, that will be chained to a JAR compile process.
If you use IntelliJ, there’s a solution to auto-reload your app everytime static files change. This one has its own problems. If you don’t edit static files from your IntelliJ and instead use WebStorm / Sublime / VSCode you need to come back to the IntelliJ window once after editing, so that IntelliJ knows that it should reload static. Fail.
So here’s a solution that worked for me: simply put static resources out of the JAR and write a URL handler that serves static resources from the filesystem. This can be done by hijacking Spring’s default /static url handler and writing your own.
Put your static file in the root folder alongside /src.
1 2 3 4 5 6 7 8 9
Include the following URL handler.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
With this in place, your spring boot application doesn’t have to be reloaded everytime you change the font-color. Happy Coding!
There’s an amazing pattern in Python, called function decorators. It’s a set of declarations at the top of a function definition, that slightly enhances how the function behaves without actually polluting the function definition with related logic. I find it a really neat way to define a function and to re-use these enhancements/additional logic across functions.
Here’s the short version:
Say, you have a couple of decorators.
One, which logs the return value of the function it decorates.
Two, which makes sure the function is called exactly and only once, no matter how many times it gets invoked.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Or you can go for another version, if you aren’t really a fan of two liners.
1 2 3
All done! Now every time you call your function, it passes through the decorators around it.
The logic is pretty straightforward considering you are familiar with higher order functions.
1 2 3 4 5 6 7 8 9 10 11 12
Be cautious when you write a decorator that modifies the return value / parameters of the function. This could cause potential breakage of other decorators.
Be careful when you decorate a method. Make sure
decoratedMyFunction is properly bound to the intended context. E.g
HexoPress, works primarily on Google Docs. But that’s not enough. There might be certain markdown elements, that you might want to use in your posts, that isn’t there yet in Google Docs – like, codeblocks?
I’ve got news.
HexoPress now understands markdown files the same way it understands Google Doc files. As usual, drop your .md files in your hexopress folder and you are good to go!
This. Should frame and hang this somewhere in my new place.
There is a systematic approach for understanding complicated systems. All it takes is a bit of predicate logic skills and a fair amount of short term memory. Everything else is drawing patterns, connecting dots, thinking it the other way and similar things that our brain already is quite capable of.
To put it in simpler terms, we can just say that to understand a complex system: we’ll need to get a lot of facts about the system and enough space in our head to fit these facts into, so that drawing out meaningful inference out of them becomes an easy thing to do.
So how do you do this effectively? One way is to gain as much facts / data about the system as possible. One simple thumb rule is that if our motive is to change/innovate/rethink the system, we need to know *everything* about the existing system before trying to work on it. So before going into the rethinking mode, gain as much understanding as possible about how the system works currently.
Secondly, when your brain works out logical results out of these dots you’ve accumulated, question them ruthlessly. Drop a *Why* wherever possible. What you are looking for are those scarce little why-s that might lead you to an alternative route, maybe a better route with better outcomes or maybe not.
One effective way to do this is to have a mind-map, or written notes of the decision tree, of all possible questions and answers that comes out of a certain *why*.
The last step is something that you’ll intuitively know–picking a tree from this map of yours.
I’d like to take you through a little tour of how to understand a complex system with example, but I’ll need a lot more time to do that effectively. That can wait. Will do it sometime later.
This is my first blog post @ hexopress.com. JFYI: I made hexopress.com.
Whatever platforms there are now, are great. Except, there is a lock-down of your writings. The platform that you choose, essentially take your writings, packages them into something that the platform can understand for itself and hides them under its pillows, merely extending you with a corner to export them – all the while hoping, you will never need to.
What if the control is inverse?
What if all your posts are somewhere where you decide it to be? What if all these blogging sites are just a conversion layer that treats your files/writings as the primary database and generate a blog out of them?
Octopress is the only one which comes very close to this vision. There’s a tiny little problem though. It’s for hackers. It assumes we will have downright access to a text editor and git, every time we have a great idea that we need to write down – which is actually seldom right.
As for me, most of my “I bloody want to start writing now” moments happen when I am somewhere far far away from my desktop.
But wait, this is an already solved problem.
All these cloud people(Google & Zoho) have been empowering me to write down things, anywhere, on any device – which is exactly what I want now. It’s just I want these blogging softwares to understands what I put in these cloud filesystems.
That’s essentially what HexoPress is. I’m excited about what it will turn out to be.
https://github.com/xwiki-contrib/chainpad - Chainpad - a collaborative markdown editor, based on blockchains
https://github.com/eriklindernoren/ML-From-Scratch - ML algorithms written in Python
https://github.com/gurugio/lowlevelprogramming-university - Pointers to resources for learning low-level programming.
https://techiedelight.quora.com/500-Data-structures-and-algorithms-interview-questions-and-their-solutions?share=1 - 500 DS & Algo Interview Questions & Answers
http://mikeos.sourceforge.net/write-your-own-os.html - Write your own simple operating system
https://azeria-labs.com/arm-data-types-and-registers-part-2/ - ARM Assembly Intro
http://www.craftinginterpreters.com/ - A detailed narrative on how to create a scripting language.
https://www.producthunt.com/@producthuntbook/collections/12-most-influential-reads-for-software-engineers?utm_source=browser_notification&utm_medium=browser_notification&utm_campaign=12-most-influential-reads-for-software-engineers - Programmer Book Collection
https://tyk.io/blog/rest-never-crud/ - REST was never about CRUD
https://www.eggradients.com/startup-directory - Product posting forffff ums
https://www.lesswrong.com/posts/xg3hXCYQPJkwHyik2/the-best-textbooks-on-every-subject - Best Textbooks for different fields