1,765 karma · joined May 9, 2011
https://notbad.software
I fixed that problem for my candidates then turned it into a startup:
Takehome is in a pretty crowded market space. It has its own distinct niche but it can be quite difficult to communicate that difference to potential buyers.
Clubman, on the other hand, has few competitors. The clients are relatively homogeneous and their needs well articulated. They're a smaller total addressable market but with a higher percentage hit rate.
I split my time about 50/50 between the the SaaS side of my business and consulting. The consulting revenue stream is much larger than the SaaS one but it's growing.
And
It's a bit iffy since if everyone did this all the time the incentive to advertise low rates gets removed. As an individual bonus, though, it means you don't need to do all the paperwork it takes to change providers.
I find that once a company uses the product, they never stop. The customer base is very sticky.
I have also found that I bounce a lot of companies that don't "get it". They don't understand that it's about making things better for candidates and so all they see is Hackerrank with less features.
My challenge for growth is finding better ways to explain the ethos and the benefits to those companies.
For autocompletion, datepickers, etc I use drop-in components. These tend to be jQuery based but it's not the end of the world.
When I do have a particular view or flow that outgrows the "bits and pieces of JS" phase it's actually pretty straightforward to use a modern UI library like React or Elm on that view alone. Reducing the scope of the area you're using the framework in rather than writing the entire app in it simplifies things pretty dramatically. The JS doesn't need to worry about routing, pushState, etc etc etc. It just deals with its own little patch of DOM and state.
Server-rendered used to mean slow and clunky but I've found that using Go my page loads are super fast. The inter-page transitions can sting a little on really really slow connections, it's true. But users are much more willing to deal with them if they haven't first been subjected to a minutes-long spinner while the SPA loads up all its libraries and state.
A little game I sometimes play is asking fellow developers to try and guess the frontend framework used on one of my apps. They click around for a little while wondering "Angular or React" before I tell them it's actually just some Go templates rendered on the server. It often opens their eyes that the loads were so fast they couldn't actually tell they were happening.
SPAs have their place and I've written a lot of them. It's amazing how far you can take server rendering in 2019, though.
Some would call it a ponzi scheme, others would call it a kickstarter.
Just don't call it semver, because if you do, people will expect it to be... y'know... semver.
The same applies to putting your not-semver version number into places where people or tools expect a semver number to be placed. If you encounter those places (like npm) please put an actually-semver number in them.
In a first world country like Switzerland it's unlikely this coercion would take place with an AK47 at the ballot box. It is, however, conceivable that it could take place on the shop floor by either a boss or a trade union representative threatening to withhold work or pay.
I wouldn't be comfortable using a system like this for a state level election. The stakes are too high. That said, I do actually offer a product that sacrifices the same property and is designed to be used in elections for community organisations, companies, etc.
My digital election product: https://scrut.in/
More information on the concept of receipt freeness: http://www.lsv.fr/Publis/PAPERS/PDF/DKR-csfw06.pdf
Google does smarter muxing of video and audio streams and is better about throttling video quality to preserve bandwidth when required.
Someone at some point in the past has created this one, for example:
And you can join it as a guest.
https://wiki.archlinux.org/index.php/Touchpad_Synaptics#Usin...
As the system matures and the edge cases become better understood it can become more automated. At first, though, leave it loose and human-powered wherever you can.
https://github.com/davidbanham/kube_maker
I've been thinking about integrating a local minikube lately but haven't started yet. I may end using Skaffold as a backend or just deprecating kube_maker entirely if it becomes obvious that Skaffold is the way to go.
I, along with 95% of the world's population, do not live in a place where Equifax exists.
Tax returns capture some things. They also don't get filed for several years sometimes. They don't capture assets like cryptocurrency or off market shares.
Life is messy and death more so.