Extracting useful information from a chat log is tedious and error prone, though. If it's something that should be saved for later, copy it over to a wiki or some such and edit it suitably.
Chat is ephemeral, treat it as such and everyone's life will be better.
But how do you get the information first. You have to look at the chat transcript - and in an international company and a problem requiring thought or research the information could be spread over a couple of weeks SO you still need to scan the transcripts.
Yes Chat is ephemeral and I can't think of cases that involved looking back a year but weeks definitely.
Chat id part of the process - if an issue is raised then the solution will be a permanent change, in my case software code changes, or an email summarising the solution for non computer issues, or chnages to documentation (if you are lucky enough to have documentation)
Another example is if you go on vacation for a few weeks the a quick scan of chat is often useful.
Reading through the comments, most of you are either new to Go or new to web dev in general.
Only that would explain how this SHITSHOW of a "framework" would get any praise at all.
What he copy/pasted already exists, only better.
The HN audience doesn't seem very sophisticaed. Hell even reddit's /r/golang is better informed than HN in this regard.
Just read through all the issues people have with gorm and if you've ever did any real Go development you would not pick gorm as the default database package in the first place.
Amateurs all of you, I'm seriously sick of your unprofessional lack of knowledge and experience.
In a fail over situation, such as a small biz scenario with multiple providers, but no BGP, you'll have to deal with rotating prefixes. One alternative would be to NAT to the other provider prefix's during fail over (actually NPt: network prefix translation.) Depending on your firewall / router this may be easier said than done.
Right. NPT is not well supported. NAT66 is out there, but when you think of address space size is totally ridiculous. That said it does solve a bunch of issues.
There's food (aka good tasting food, which was exposed to the sun and grown in the open) and there's FoOd (aka tastes like water, grown under glass).
Most of the food you can buy nowadays, even on "local markets", is the latter variant.
Cheaply produced without taste or value that lasts for weeks without going bad.
Unhealthy food. And it's making us more stupid because we don't get enough of the nutrition we usually would.
I remember the story about 2 girls from India who moved to the UK.
They would get ill and no reason could be found until someone had the idea that the food in India was actual natural food, and the food in the UK was this watered down food.
How often do you eat a tomato nowadays that tastes like a tomato and not like a watermelon without the taste?
Glass in between the light has absolutely no relation to taste or other properties. My own best veggies are grown in a greenhouse. It's about the soil and what you grow - commercial strains are not selected for taste but durability/good looks. If you grew the same commercial strain """naturally""" you'd still get bad taste.
I had a github profile once, but a conflict with the Go team lead to my account being blacklisted (flagged). So I deleted 150+ repos from it and the account.
I host my own gogs and recently gitea instances now and there is little public code there.
The public code is not representative and I won't give you access to my private code.
I also won't do pre-noon interviews.
If you start pressuring me I'll revoke the application.
You can be lucky I even applied to your company, despite all the bs buzzword requirements you have posted you have no clue about what they mean.
I am very angry at current hype driven job ads.
And yes I wager they're more of an ad for the company than actual job ads.
From some ads where I sent my application to I have never even heard back, which means they probably sold my info.
Even reading all those job ads is tiresome. Most don't even write if they're ok with 100% remote. Most don't even write if it's ok to not work 100% full time. Most don't write how much they're willing to pay.
Most job ads are just a waste of time spicked with bs trendy buzzwords.
git repo
/var/www/domain_name
git clone git_url /var/www/domain_name/backend/
cd /var/www/domain_name/backend/
go build
Updates
git pull
go build
systemctl restart domain_name.backend.service
I pay 46€/month and I'm looking forward to halve those costs.
Server load is mostly <0.5
I call this the incubation server.
If a project takes off I rent a more expensive, but dedicated, server.
It's very unlikely that I ever need more than 1 single server per project.
I will never write microservices, I can scale fine with a monolith.
Lately I even moved away from JS frontends to render everything with Go on the server.
Yeah it requires more resources but I'll gladly offer those resources for lower response times and a consistent experience.
Sadly companies that are hiring don't see it that way. That's ok. I'll just stay unemployed and try building my own stuff until something succeeds again.
I had a 7 year long project that brought in 5-7k€/m. The server costed 60€/m.
I can do that again. I know it's not your kind of scale or income level, but it allowed me to have a good life living it my way.
I think it's somewhat disingenuous to compare DevOps requirements of 5-7k/m projects with systems run and operated by companies in the mid market.
That said, something I often wonder about is if you could minus out 100% of the cruft systems run by realistic sized companies, exactly how cheaply could you run them and with what DX? Half of the problem is things built by 100 people with competing and shifting priorities will never result in a clean, tidy, sensible system and it's mighty difficult to minus out the effects that the organization scale has on the end result.
I'm currently working through building a hobby project on that as far as I know will only ever have one user, but I'm enjoying the total freedom to take my sweet time building it exactly as nice as I wish the systems I wrangle in my day job would be and I'm 100% looking to run it for free or as close to free but with as much performance as I can get because why the hell not? It's a totally different ballgame.
I didn't understand half the things you wrote.
What's a company in the mid market? (nm I looked it up)
What cruft? Not a native English speaker, you way of expressing yourself is hard to understand for me.
DX?
Are there really things built by 100 people, if so, why do you need 100 people?
Why can't you do with 1 lead 1-2 database guys 1-2 code monkeys?
Why can't this be done in a monorepo and a monolith?
Why does it have to run -in-the-cloud- on other people's computers?
I had a project that was ranked in the top 1000, according to Alexa, on a single server.
But it didn't bring in enough revenue and took up most of my time so I shut it down.
I re-launched it 15 years later but it's dead. No one knows or remembers the domain anymore save for bots who keep hitting those "fkk-sex-nude-porn" etc spam links.
Back then you could make a site popular with 1€/day on Adwords, nowadays ... lol, this won't even lead to your ads being displayed, anywhere.
Go can handle 500 million visitors per month on 10 year old hardware (= 1 server).
Which "mid market" company has 500 million visitors per month?
Writing websites/apps isn't complicated. For me anyway.
You figure out the data models, write the use cases and you're half way. The other half is writing the display layer to make use of that data.
You make it all sound like the requirements or the product is different. It's not. It's all the same. You can have observability without k8s. You can scale without k8s. You don't need a managed database.
Man this stuff is simple. It's people how are trying to sell you cloud and microservices and whatnot that make it all sound so hard.
A good software developer if spending his knowledge and lifetime to build something for you that is built to last, because you can't apparently do it yourself or don't want to.
It will last even when he isn't part of your company anymore. He could've built the same for himself and monetize it, instead of bowed down to you (not your personally) and opted for steady income.
I understand how, let's be honest, when we talk DevOps we mean k8s, so I understand how sweet a siren's song k8s sings. But it's ultimately a waste of resources. It's a solution asking for a problem.
Until you reach proportions that require k8s you'll be completely satisfied with a 3 server setup, that is Go and pick a database. I promise, I guarantee.
That 5-7k/m project had 30 people concurrent at most. It had 30TB/m outgoing traffic at most. How much does 30TB egress cost in GCP,AWS etc? It used to be about 3k, I believe it's 1/3 of it now.
Why would the principles that are valid for a "small" project not apply to a "mid market company"? More features? So what? The principle remains the same.
Boring, same old. Data models, wrappers, display layer.
It's the same for all, your beloved FAANG, mid market, small business, single owner.
No one ever said a VPS with a shell script is terrible. You think of scale the wrong way. Scaling is not only about increasing from 10 requests / second to 1000 requests / second. Scaling is about organizational scale too, i.e. how do you ensure going from 2 to 20 developers increases productivity by at least 20x and not 1.5x?
Tools like Docker, Kubernetes and whatever absolutely help in that regard.
But it does have way to query, if you of course only know SQL and didn't bother to learn the MongoDB way to query then for you, the uninformed outsider, it might seem complex.
But so does ArangoDB or Neo4j or GraphQL.
Like, if you were never exposed to rxjs and are now trying to build things with it doing
$stream.pipe(
switchmap(),
filter(),
etc(),
)
It does seem more complex than
stream.map().filter().etc()
but it's only so because you haven't put in the effort to learn that way.
Now write DBA scale ISO SQL 2016 / Transact SQL / PL/SQL in that interesting Mongo flavoured language, including database engine debugger integration, and JIT compilation.
1. MongoDB is not complex, the driver structure sucks.
Example Go's mgo driver by Gustavo Niemeyer was simple and effective, but abandoned.
The official drivers is unnecessarily complicated.
And Go's need to have "context" everywhere adds to this, but MongoDB is not complex.
Idk I'm not some super genius and picking up MongoDB was really easy.
Querying (aka aggregation pipelines), you have to think of that as "pipes in bash". It's in the words aggregation pipelines. find | groupby | sort | filter | select.
Something like that. It's not SQL it's different, but not complex, sorry.
Use something that can be searched, and doesn't require one to have an account to read the messages and/or search.