Solo founder at Emysound[1].
Started 10 years ago as an open-source project, building an algorithm for audio fingerprinting. Added a commercial offering, selling storage built specifically for audio fingerprints, targeting enterprise customers. Since the offering was too technical (it's hard to sell solutions to problems that are too narrow and domain-specific), pivoted to more "business-oriented problems". This last year's pivot is a chance to finally grow. Running a business in single-player mode is, at times, too stressful. Aside from the technical part, which I very much enjoy, I need to wear marketing, sales, and customer support hats.
I'm really not good at marketing. Essentially I have to learn how to do it first. I plan to spend more time learning this new skill and then applying it. I've been recommended this [1] course, and if anyone can recommend something that worked for them, that'd be great.
Balancing it with other duties is going to be hard, though I will try to explicitly divide my time into "one-week marketing / one-week dev work." Inside each week, I will try to have days fully reserved for non-work activities.
Programming keeps me in this perpetual cycle of "one more thing for today/this week" which locks me in the IDE without end in sight. I will postpone any dev work that needs to be done until "dev work week" arrives.
My goal for the next year is just to work fewer hours. Covid pushed my work habit to the extreme, and I need to rebalance.
1. Read more books, less social media/news.
2. Spend more time with my friends. I haven't seen some of them IRL for more than a year.
3. Exercise more, play tennis with my daughter, spend quality time with my kids.
4. Spend more time with my parents. They've become visibly older in the last years, an observation that scares me.
5. Focus more on marketing for the businesses that I've bootstrapped. All the shiny new features that are developed are not as important as getting more people to use your product.
6. Promote open-source project to 1k GitHub stars[1]. I know it isn't very meaningful, but it's just nice to receive a bit of recognition from the community.
7. Enjoy life, don't stress about all the little things that happen along the way.
This reminded me of Sergiu Celibidache, a revered and criticized conductor who had a different opinion about tempo on major classical works.
He viewed his performances more as "experiences" and certainly pushed the boundaries of the conventional style of playing classical music.
I really like his renditions of Bruckner, and the ending for Symphony N4 probably best describes why [1]. He does not rush, letting the music sync in, undoubtedly different from the "right" version.
Not being afraid of criticism is an essential quality of people who discover new things. Smart people often get dragged into the "correct", "proper" way of thinking, doing science, playing music, drawing, or doing other creative work. This is the best way to learn, but unfortunately, you need to go on an unbeaten path that is often criticized and even ostracized to discover new things. The life of Van Gogh and many others is quite an example of that.
For binary vectors you can choose a different distance metric (not geometric one, i.e. Jaccard) that can be used to effectively hash similar data points into similar buckets.
Treating your binary vector as a set allows you to use min-hashing as your LSH schema (min-hashing is just a random permutation of the given set). This simple trick makes LSH with min-hashing quite a powerful tool for binary vectors that are extensively used in recommenders systems and other domains.
I've used LSH + Min-Hash for image search (and subsequently for audio fingerprinting). If interested, I've blogged about it here [1].
If you delist your Shopify app from the app store you will not have to pay the 20% monthly commission from the new customers. It also means your app is private, and you will have to invest in your distribution channel now. Shopify stores can install it as a Private App, which means you will need to find new customers on your own.
On a different note, I wouldn't recommend building an app that is strongly integrated into the Shopify platform due to a myriad of reasons.
Shopify App store will not give you enough exposure to grow your customer base naturally, you will have to invest in your distribution channel anyways, but now you are tied to a 20% commission since your app is public.
App store ranking system is heavily tuned towards the rate of installations your app has, which means products that offer free, or very cheap pricing plans are getting to the front page. If you offer free or very cheap pricing you will get inundated with customer support requests. The biggest chunk of Shopify customers, have very little understanding how to run an e-commerce store. Handling these requests will be a nightmare. This also means that the Shopify App store is not used anymore by stores that are running on Professional or Shopify Plus platforms, since it is full of apps that are borderline scam, and they can't find valuable services by a simple search.
Shopify understands this as well, that's why they've created Shopify Plus Certified App Store https://www.shopify.com/plus/partners/technology, which is essentially a curated Shopify App store targeting customers who are not afraid of paying money for valuable services. Getting there is not easy since the certification process is not transparent (we've applied but not heard anything from Shopify since then).
Also, Shopify integrates new features into its platform every year getting into more and more verticals. This essentially means that if you build an app that provides important e-commerce functionality, Shopify will probably release the same feature integrated natively into their platform.
All in all, don't bet on the Shopify App Store distribution channel, it is just not worth it.
Very thoughtful point. I was concerned about it as well. Rushing a half-backed vaccine that has serious side-effects will fuel antivaxxers for decades.
One of the most challenging things in growing a software product is managing complexity. If you are designing a product for future use cases, you add complexity upfront. To keep a healthy balance, I try to follow simple guidelines:
* Focus on the current assignment. Implement it using clean code principles, don't overthink the problem.
* Rather than spending time on design decisions, allocate time on handling edge-cases. These will save you from PageDuty alerts.
* Plan excessive for future use-cases only around data models that insert/read into the database. Data migration is super-painful. A more generic design around your database is almost always preferable.
* Have a feature toggling[1] service in your codebase. It will provide you with a better understanding of how you can implement new features alongside existing codebase in the same branch. Releasing features from long-running separate branches is almost always a wrong decision.
* Always keep in mind time-constraints and how urgent is the requested functionality. Don't let perfection be the enemy of productivity.
* Have a process in place that allows for the technical debt tasks to be tackled independently. It helps fix some bad design decisions, which become apparent in light of new requirements.
There are a couple of concepts in F# that I really like:
* actor-based approach to concurrency[1]. Very useful when you want to design your code lock-free. Treating instances as agents that read messages from a mailbox, frees the developer from using low-level threading primitives. First time I've used this approach in production with AKKA and Scala. In F# it is much cleaner because the language itself is built on a better platform.
* exhaustive pattern matching[2]. Writing in F# means using pattern matching a lot. Exhaustive matching gives you the confidence to refactor and maintain your code. The compiler will warn you when adding a new value in your type and not covering the execution path that uses it. It catches a lot of errors before you even push the changes to CI.
* obviously immutability, conciseness, currying, these have been mentioned so far by others.
One nitpick in F# are Exceptions [3]. They approached it similarly to how it is done in C#. You are allowed to define and throw an exception that will "jump" somewhere in the execution path.
I prefer when a method returns Option-style types. This way, you know what to expect from a call, and pattern matches on the result without adding one more execution path in your code, which covers exceptions separately. It was added to support C# style error handling, though I very much prefer an error-code-based approach.
If you want a more interactive source you can play with python notebooks from the music information retrieval site [2]. I've found it helpful, as you try some of the described music theory concepts in a programming environment.
Shameless plug, I've also written about how audio fingerprinting works [3], which touches on some of the topics regarding music theory.
Radio/TV broadcast analytics is the most frequent use case. At least I receive a significant amount of questions regarding it, so the library has been optimized for this task. YouTube ads detection is also an interesting case that falls in this category.
Other use cases are divided between game development, repeating content detection, robocalls detection, or just iOS/Android apps for Shazam like style features.
Surprisingly a couple of times, I was asked about recognizing birds by their singing. The library can't do it, but it is something I am thinking about exploring one day.
I've been working on SoundFingerprinting [1] for almost ten years now. Its Shazam for developers. First 8 years I worked mostly during my free time and weekends. 2 years ago, I decided to monetize the storage for the fingerprints. There is a MIT licensed version of the storage [2], and a commercial one [3], which is fine-tuned for thousands of hours of audio or video content. If you are an enterprise customer, you will essentially need it at some point, and will most probably have no problems paying for it.
Overall I invested a lot more time in it than the monetary reward I received. I don't complain since I enjoy working on audio/video fingerprinting and databases. On top of it, the pay at this stage is on par with a regular SE job with the bonus of working on things that I enjoy. I can call it a bootstrapped business now.
In some sense, I think about opensource similar to the work of art. You do it because you genuinely like to create/build things and showcase them to the general public. You don't do it because of the monetary reward. A good writer is one that has to say something, not one who writes for the sole purpose of getting on the NT bestselling list. Opensource is similar.
The crypto industry at its current stage is far from any practical purpose. It's just unfortunate that "Haskell in Practice" is associated with crypto BS.
I was born in the USSR and it also had it's "own way". And it didn't resist even 70 years. The elephants in the room mentioned by others in the comments are all "meta" things at the highest level of human cognition: basic human rights, freedom of expression, religion, overall civil liberties are all above any "<insert nation> ways". Cultural differences are just irrelevant here.
It's the same narrative all over again. When no strong arguments are present to defend a viewpoint, the topic suddenly becomes a "cultural" thing. Sounding smart and mysterious. In Russia, it's "the Russian way", in China it is "the Chinese way" etc. It's just BS.
If you switch to non-lidar mode for unfavorable condition, why don't just use the non-lidar for all conditions. A system that is safe for unfavorable conditions is likely to be the system that is safe for all conditions.
First example I've checked is wrong [1]. Shuffle a list, with a static Random object initialization. Using a static random object is not thread-safe in .NET.
"One common solution is to use a static field to store a single instance of Random and reuse it. That’s okay in Java (where Random is thread-safe) but it’s not so good in .NET – if you use the same instance repeatedly from .NET, you can corrupt the internal data structures." [2]
Very often the very same resources which claim to be the source of truth provide bad code examples.
[1] - https://emysound.com [2] - https://github.com/AddictedCS/soundfingerprinting