I've used slack channels a means for application event and error alerting for years. The webhooks are super low friction and and Slack is often center of a teams work life.
The pain comes from repeated messages. If something fails 100 times, you're going to get a 100 messages. That's a strong signal, but might also be noise that covers up other errors. Plus you have to go in and individually delete all those message.
Over time, I've made improvements to the stock webhooks functionality. Rolling up repeating messages. Threaded logging. Bulk deletes. Recently, someone suggested I release it into the wild. Here it is.
Hmm, I was able to launch a c2-standard-8 without any problems. The e2 instances still don't work. Maybe google is pushing us towards the more expensive SKUs!
I usually buy a refurbished or new dell XPS-13 that is one or two generations behind the current Intel offering. Runs fedora and ubuntu perfectly and should cost about 1K. I usually get them on ebay:
I'm looking for someone to act as a part-time project manager/scrum master/jack or jill of digital trades.
Initial tasks would include:
- grooming a trello based kanban board, adjudicating bug reports and elaborate feature requests along with CTO and founder.
- formulating acceptance criteria and carrying out acceptance testing for work items in a local development environment and deploying code to gcloud.
- run ad-hoc scripts when requested and perform ad-hoc sql queries to answer questions the founder might have.
Able to pay $50-75 per hour depending on experience and imagine this starting as a 15 hour a month job growing to quarter or half-time within a year. If the person is able to take on additional responsibilities (either managerial or as a coder), the rate could go up $100 per hour.
I imagine this would be a good role for a young person starting out or even in school, a stay at home parent looking to supplement their income, or a retiree looking to keep their hand in the game.
Preference given to folks in the NYC metropolitan area.
The accepted story is that involved in bringing something successful to market has to have vision (the idea for a better "mousetrap").
Do they also have to have something like passion? Plenty of organizations bring software to market based on rational analysis's of possible market share, cost of customer acquisition, life time expected value, etc, etc.
If you are a talented maker of software, you can hitch your cart to someone else's dream. The world is full of way more ideas than people who can bring them to life.
Find an idea you think has legs and place a bet on it. Place multiple bets, if you can. The "fractional CTO" is a thing now.
Many things have changed my mind. Most recently it's been the move towards thinking in terms of data processing. Solving problems by transforming data structures.
The gateway drug was transforming json with lodash/underscore/ramda. Clojure cinched it.
Given a software product with a modicum of market fit and or an established user community, AND a competent engineering organization, there is no reason to have technical debt in 2018.
>>To summarize, it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices.
I read the article a few days ago and was struck by what a poor idea it was to take a hundred or so functions that do about the same thing and to break them up into a hundred or so compilation and deployment units.
If that's not a micro-service anti-pattern, I don't know what is!
I was going for a clean presentation of a concept (and a gentle nudge in the direction of FP) in the article.
You raise important issues.
I would say, when you can, rewrite your code so you don't have to worry about such things.
Roll back everything under your control in the event of an error, and if there are side effects beyond your control isolate them at the end of the composition.
If two functions return the same exception, you can always wrap one of them so it returns a different one.
If a function needs it's own stand alone exception handling, do it in there.
If it really is necessary to know one could introduce some sort of monadic error handling that wraps up the results of all the functions including their place in the composition.
But really I would try to rewrite my code so that I wouldn't have to do that.