HN user

brimstedt

244 karma
Posts2
Comments141
View on HN

I do not agree fully with this article, but it does give food for thought and have some valid points:

- 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.

K8s with 1M nodes 9 months ago

It's an interesting and fun experiment, but what are real usecases for such a cluster?

Why? It seems to go along well with the rest of their services. Slow, feature incomplete.. Just look at Jira, Confluence, etc.

We use the atlassian products at work and are planning to replace Bitbucket with Gitlab within short.

Any initiative to make a fast powerful UI is a good one imo.

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.

I remember only one lecture from university, one in presentation technique.

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.

Nice work

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...

I think it's a great idea if it's done right. I miss freshmeat.net :-)

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 rarely use Chrome myself. Firefox in my opinion is less opinionated and let me use it the way I want.

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

I see a lot of comment reflecting on MySQL and oracle vs postgresql.

Anyone with experience of MSSQL and PostgreSQL who'd like to comment on how it they compare?

Goodbye MongoDB 3 years ago

Id say the point of nosql is rather "the right tool for the job".

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.

I think I get your sentiment, but what I think is the funny part is that when you PAY for apple HW/SW you are not allowed to use it as tools, instead it's locked down.

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.

Kind of odd generalizing 'smart'. People have different skill sets and it's pointless comparing eg dev skills with marketing skills.

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.