brimstedt
- don't blindly jump into a new architecture because it's cool
- choose wisely the size of your services. It's not binary, and often it makes sense to group responsibilities into larger services.
- microservices have some benefits, moduliths (though not mentioned in the article) and monoliths have theirs. They all also have their set of disadvantages.
- etc
But anyway, the key lesson (which does not seem like a conclusion the author made) is:
Don't put a halt to your product/business development to do technician only work.
I.e if you can't make a technical change while still shipping customer value, that change may not be worth it.
There are of course exceptions, but in general you can manage technical debt, archtectural work, bug fixing, performance improvements, dx improvements, etc, while still shipping new features.
Afaik there is no universal way to handle numbers in alphabetical lists. Sometimes numbers some before letters, sometimes after, etc.
A digit is not a part of the alphabet, right?
Not necessarily true. Id like to replace jira in an enterprise environment and we do need sso and prefer to self host.
We use the atlassian products at work and are planning to replace Bitbucket with Gitlab within short.
It worked well in ff on Android, except i did not see the final set of words in the end and share link got undefined in it:
I completed today's Fragment in 03:59. Think you can beat my time? Give it a try: https://playfragment.com/?=undefined
Some features, like clipboard history and window management (i.e "tabs") are better left to the desktop environment though. Every app shouldn't need to reimplement this logic.
The idea of the (guest) speaker was that when you hold a presentation, say the most important things first.
If anyone gets up and leaves, or the presentation is cut short, you should've gotten the most possible value out if the time.
Then dig into details as the presentation progresses and answer questions or concerns right away.
Answering right away does not mean side track the whole presentation, give the major response and take details later.
I.e "TL;DR" your presentations, oral or written alike.
A simple example is: you've been given the task of estimating the cost and work involved in developing a new feature.
When you present your result, don't start by listing all the things needed to be done and all the investments needed to be bought.
Start by giving the receiver what's on her mind: what is the price, when can we deliver, how many persons do need.
Then dig into the overall details of how you ended up in that, perhaps that the tools needed to be purchased are X, Y and Z.
Then dig into why we need those tools, and so on.
If you have to interupt early, or if you have a big trust from the receiver, the main point has been delivered and the the remaining 80% of the time can be invested in more important things.
I've applied this in my life, privately and professionally, and it's been working out well. I also hope this response was a good example of what I tried to pass on.
It would be neat if there was an option to make input and textarea use the script font as well and an image component that made a sketch of the image provided.
And maybe charts, and...
A database of open source software would help when looking for suitable products, personally I tend to scout for open source options before looking into closed options.
If it contained easily searchable/filterable information on license, "activity" (i.e how alive the project is), hosting/deployment options, development language, operating system, it would be great.
Also if it has info on how it accepts contributions, it'd be nice.
Probably you could scrape I formation from GitHub, gitlab and similar sites and you could also let projects supply information for you in a "oss-info.yaml/json" in the root dir of the project.
I still find Firefox superior to safari.
For example, in vscode if the sharer start a http-service the port can be port forwarded through the session so anyone in the session can interact with the service.
Pretty neat and useful!
For example, it's much easier in FF to not use tabs, which is important to me.
Also I want to support them because I think Google is getting to strong overall and a monoculture is no good.
I wish more Devs/IT people would use ff and lead the way for their non techie friend and family
Anyone with experience of MSSQL and PostgreSQL who'd like to comment on how it they compare?
What did you use to charge and why did you stop?
You can use an SQL db engine as a kv-store, but you can probably make a more efficient kv-store if you do not have the SQL constraints.
(Oth SQL engines are pretty efficient for lots of use cases these days)
Another example where SQL may not be the right choice is time series or graph DBs.
Pricing matters of course. I get really ticked off at the overprice of many SaaS.
I gave up on iOS devices a few years ago when they forbid things like 'wifi scanner' on iOS. A tool I used regularly to install and measure the quality of WiFi network/coverage.
Imo, Jobs was good at making hype, that was his skill set and he was undoubtedly good at it. Woz, Torvalds, have very different skill sets from his but it's apples to oranges.
How many documents do you need for it to be usable?