It's one of the few CI tools where you can test your pipeline without committing it. You also have controls such as only pulling the pipeline from trunk, again, something that wasn't always available elsewhere.
However, it can also be a complete footgun if you're not fairly savvy. Pipeline security isn't something every developer groks.
If you choose wisely, things should suck less overall as you move forward. That's kind of the overall goal, otherwise we'd all still be toggling raw machine code into machines using switches.
This is it right here. My foil is the Elasticsearch replacement because PG has inverted indices. The ergonomics and tunability of these in PG are terrible compared to ES. Yes, it will search, but I wouldn’t want to be involved in constructing or maintaining that search.
The consequence of running ingress and DNS poorly is downtime.
The consequence of running a database poorly is lost data.
At the end of the day they're all just processes on a machine somewhere, none of it is particularly difficult, but storing, protecting, and traversing state is pretty much _the_ job and I can't really see how you'd think ingress and DNS would be more work than the datastores done right.
Now with AWS, I have a SaaS that makes 6 figures and the AWS bill is <$1000 a month. I'm entirely capable of doing this on-prem, but the vast majority of the bill is s3 state, so what we're actually talking about is me being on-call for an object store and a database, and the potential consequences of doing so.
With all that said, there's definitely a price point and staffing point where I will consider doing that, and I'm pretty down for the whole on-prem movement generally.
I'm generally strongly in favour of bare metal (not so much actually on prem) but your case is one of the rare cases wher AWS makes sense. Even for cheap setups like that, bare metal could likely be cheaper even factoring in someone on call to handle issues for you, but the amounts are so small it's a perfectly reasonable choice to just pick whatever you're comfortable with.
That's the sweet spot for AWS customers. Not so much for AWS.
The key thing for AWS is trying to get you locked in by "helping you" depend on services that are hard to replicate elsewhere, so that if your costs grow to a point where moving elsewhere is worth it, it's hard for you to do so.
Tech has built literal industries of people trying to stress you out, and they mostly don't have actual tech skills or the empathy that comes with them so back it up.
For me, I usually try to avoid anything where the working practices are strongly defined. Agile has long been a bad word.
Unfortunately while the intentions around agile were noble it's pretty much a direct way to burnout or worse. The human mind is not designed to "sprint" run a marathon, metaphorically speaking, forever.
I see older devs being active in the trade well into their 60s but even as I much younger person I don't see how agile development is sustainable for a ~50-year career.
The thing is, the core agile points from the manifesto are pretty much universally fine and can pretty much be boiled down to, "make changes fast, get feedback, gain more understanding faster".
Pretty much everything that's been layered on top though has either nothing to do with the manifesto, or actively breaks it. i.e. there's a burning issue, I'll get to that after my sprint commitment, which was sold to let me finish work, but now only exists to stress me out to squeeze more widgets per unit of time, where the widgets pretty much never actually map back to anything actually tangible.
Scrum is like Spaghetti Carbonara in America. The ingredients are simple and there's a tiny bit of technique involved that anybody can figure out after a few tries. For some reason though almost everybody that makes it decides that they know better than the people that invented it and so adulterates it with peas and onions and garlic and cream and cream cheese and Italian seasoning and parsley and chives until it ends up being Olive Garden Alfredo. If they wanted Carbonara then they would have cooked the Carbonara, not the waterfall with a bunch of JIRA workflows and four-hour meetings layered on top. They just did what they would have done anyway while attempting to sound fancy via obfuscation.
It's not just Agile but the same applies to DevOps.
DevOps is a culture. It can also be the specific subset of highly skilled individuals who were part of or an outcome of said cultures cross pollination. Today DevOps most often means fairly unskilled person hitting pipelines with hammer.
In the end, the same old people with the same old commercial interests adopted the term in a way that benefited them but changed the meaning of the term because change was not actually something anyone wanted.
That's not actually true. To give a silly example: does anyone (seriously) claim that 'true fascism' has never been tried?
Or: liberal democracy (I'm sure you can find a synonym that ends in *-ism) has been tried. It's been doing ok-ish. Obviously it has warts and all. But more importantly: approximately no one ever seriously claims that 'real liberal democracy' hasn't been tried.
Similar for constitutional monarchy, or 'social market economy', or dictatorships, etc. People can mostly agree that the real deal has been tried.
Any principle or practice falls apart when tied to an economy. See also: religion, politics, society at large. I don't foresee that changing in our lifetimes, so make money doing it the wrong way, and do it the right way in your free time.
I don’t agree with that though, plenty of places practice agile well. Maybe big corporations don’t practice it well, but startups often do agile correctly and understand the philosophy.
Inasmuch as Agile was adopted at companies, it's because it was sold to them as a way to provide greater transparency, accountability, and control into a chaotic software development process. The vice president behind the company's "Agile Transformation" probably can't even name point one of the manifesto; "we're doing Scrum with JIRA, therefore we're agile" is the extent of his concern.
You say that, but it was way more stressful pre agile with the fixed date, fuck around for a few months planning, then dev, run out of time then death march to finish, etc.
A lot of young guys like that D-Day style work, then goof off for a while, but not me. Continuous sustainable work is much preferred.
There's a difference between "bad PMs using the tool wrong" and "ordinary, human PMs using the tool in the way that common business incentives would lead you to predict they'll use it".
If the tool is used wrong most of the time, it's at least partially to blame.
"If the tool is used wrong most of the time, it's at least partially to blame."
Only if there were other tools that didn't fall victim to the same business incentives, but they all do.
I've had PMs that find a balance with the business incentives and make it work. If you’re human and make the wrong choices, then most people, including me, will likely call you bad in that context. If they can't stand up to find balance with the business incentives, then they're a bad PM. That doesn't make them a bad person.
I have seen Scaled Agile Framework (SAFe) work in multiple real program teams. Doing it successfully requires total commitment at multiple levels and many organizations are culturally incapable of making the transitions.
To be clear I am not claiming that SAFe is necessarily the best possible methodology. There is certainly room for improvement. But empirically it can work in real life.
The organizations I've seen do SAFe at the top level "coincidentally" have so much in the way of resources that if they do software at the group level at all, they do it like a gentleman farms.
"I mean if something doesn't ever work in real life then its not good."
Are you talking about Agile, Waterfall, or project management in general?
I've seen Agile work just fine. I've also seen it fail miserably. I've seen both of these at the same company with the main difference being how aggressive/delusional the leadership is. The easy test is if your leadership is legitimately ok with your team going home early if you complete your sprint commitment early, and it actually happens on occasion.
It feels like over the past decade or two, every company that builds software has gradually adopted the same terrible practices as is commonly found in game development studios.
That is why more advanced agile methodologies such as SAFe use the neutral term "iteration" rather than "sprint". It doesn't imply anything about team velocity or individual workload.
The term "iteration" was in common use by many of the big 90s proto-agile methodologies (think RUP et al). And XP - which I guess is what most people would regard as the first "true" form of agile - used it too.
SAFe is just an attempt to mush something that like looks like agile to delivery teams together with something that fits into more traditional program management, governance, and strategic direction lifecycle models.
There's no particular magic to it, and it's probably better to think of it in terms of being an "enterprise variant of agile" rather than a "humane variant of agile".
Yes, that's accurate. In the real world sometimes software programs have to make compromises in order to align with actual business needs. Like if you're going to be manufacturing hardware to go with the software or scheduling training for users then you have to apply strict program management discipline to ensure everything comes together at the correct time.
Sure, that's fair. In the real world there are a lot of developers who want to be told what to do, or need to be told what to do because they lack business domain knowledge. A defined methodology like SAFe allows large enterprises to move forward at a steady pace and get some productive work out of those people.
The reality is that in some domains there just aren't many developers who are highly motivated, self directed, and thoroughly understand customer needs. Those people just aren't widely available in the labor market regardless of wages or working conditions. So if management doesn't impose a fairly strict methodology then then the program will collapse.
I'd make a separate case that learned helplessness is a reversible thing, and more highly motivated and self directed devs can be grown.
But leadership has to incentivize not just being a ticket monkey, and needs to mindfully empower people. You can't just flip a switch in a feature factory and say "fly my pretties, be free!"
Sure, that's also fair. But it takes a long time to turn culture around. And in the meantime the company has to continue shipping releases to customers or else they run out of cash and everyone gets laid off.
In my experience of it though (only two workplaces, but not one) it's used for higher level planning, rather than being a 'more advanced agile'. I.e. a SAFe iteration spans some number of sprints greater than one. What are we going to deliver this quarter versus how are we going to break down and monitor progress of the quarter's deliverables week by week. (Don't read that like I like it.)
I think you're confused about the terminology. SAFe doesn't have sprints. Depending on the program planning horizon, several iterations can be grouped together into a larger program increment which typically lasts about a quarter.
Why is anything supposed to be sustainable for a ~50-year career? That’s a long time! Things change and people change.
It’s not like my great grandparents had a passion for farming in South Dakota and that’s why they did it until they dropped dead. It’s all they knew and what they did to survive.
If you gave them the option to tap on a keyboard in an air-conditioned room for 10 or 20 of those years they would’ve taken it.
Agile (or rather modern management) converts human capital into capital as fast as possible. Considering the endless supply of developers and lack of accountability there is no downsides to doing that, you are an externality.
Reminds me of this Indian boss I had whose only agenda used to be calling me up and telling me that others had complaints about my work. After 2 years of listening to his stories, I had to tell him off one morning. I quit about 4 months later. The guy was a completely talentless aggregator. I don't get how some Indian firms promote people and this wasn't a small firm either. He ended up being promoted upwards.
> For me, I usually try to avoid anything where the working practices are strongly defined.
I'm grateful I've managed to avoid this so far. My favorite place to work has been more akin to "we need X done in Y system before Z date, but how and when it's done is up to you".
The worst part is how these people almost always work on the most boring, rote crap. They could be selling mens hair loss medication on the internet (cough) and key individuals in the organization are convinced what they do is life-and-death, future of humanity, work nights and weekends, we're the next Google. It's so deeply cringe-worthy. Meanwhile, I know a ton of people in the traditional pharma industry (e.g. not Novo, but Novo-adjacent); those companies broadly treat their employees pretty well, very minor amounts of overwork, they're well-staffed, some still have pensions, people spend their whole working lives there.
Tech sucks. It's filled with talentless hacks who think "because we use computers" means you've got a blank check to make every individual do the work of three individuals. And then your company gets gutted by private equity anyway, because it turns out hiring talentless hacks and overworking has consequences.
This is a weird take, but I genuinely and deeply believe the world would be a far better place if everyone experienced a life-threatening but recoverable major medical event and/or had children, while young. Perspective-shifting events that are core to the human condition and help ground your reality in work not being everything. By the way: The businesses our society would build would also be stronger.
Ordering System is a good example because you typically want both. Your base logic will probably exist in OLTP with joins and normalised data, and you'll generally have local on-device OLTP databases.
Reporting on your Ordering System is an OLAP problem though. Generally an OLAP database stores data on disk in a way that it only needs to read the selected columns and the performance is better with wider columns, i.e. lots of duplicated data ( JOINs are slow ).
So like, you select * from Customer, Order, Items, Device, Staff, stick it in your OLAP database that's where customers should generate reports. This both makes reporting more performant, but it also removes the problem from the critical path of your POS device syncing and working.
This has the added benefit that updating your product name won't update the historical log of what was done at the time, because what was done at the time was done at the time ( but you can still map on like productId if you think the data is relevant. )
At scale you want to pop the writes on a queue and design those devices to be as async as possible.
This is what happens when you just build it pure OLTP.
This was an ~£19m ARR POS company dying because of architecture, now doing £150m+ ARR. ( the GTV of the workloads are multiple times that, but I can't remember them ).
> Reporting on your Ordering System is an OLAP problem though. Generally an OLAP database stores data on disk in a way that it only needs to read the selected columns and the performance is better with wider columns, i.e. lots of duplicated data ( JOINs are slow ).
This sounds like the one big table approach. Which in my experience is very difficult to do right and only makes sense in the data mart sense.
Google’s Adsense data model I’m BigQuery is like this and works well but gets so wide it’s difficult. Then again when you imbed things like arrays and structs and can unnest as needed avoiding joins can be nice.
I’ve found star schemas to work out just fine in data marts. Just do them properly. Join as needed. And a good engine will handle the rest. We’ve has no issues with a similar model in Snowflake for example. Of course YMMV.
Right, you want both, which is why databases like Oracle can store data in both forms. You can enable columnar formats on tables for both on disk and in-memory modes, where those columns can then be processed at high speed with lots of SIMD operations, but the data is kept consistent between them.
FWIW SQLserver can do the same with its column store tables. Idk though. I stopped using such when I moved to data Eng and we just use open things (clickhouse, DuckDB, etc) except for snowflake.
You wouldn't be publishing patient visits publically, the only folks that'd legitimatly see that record would be those which access to that visit, and they'd most likely need to know the time of said visit. This access should be controlled via AuthN, AuthZ and audited.
You'd also generally do a lot of time-based lookups on this data; what visits do I have today, this week, and so on. You might also want an additional DateTime field for timezones and offsets, but the v7 is probably better than v4 for this usecase.
You probably shouldn't / don't need to use v7 for your Users table because the age of your User probably has limted to no bearing on the look up patterns. For example, our Steam and Amazon accounts are pretty old, but we likely still use them.
However, your Orders table is significantly more likely to be looked up based on time, so a v7 makes a lot of sense here.
Now I'd argue the security implications are overblown, but in general tems you might also allow someone to look up a user, i.e. you can view my Steam profile, or maybe my Amazon wishlist. You probably don't need to be looking up another Users Order.
Alternativly, if your building an Enterprise Risk Solution, you could take a view that you don't want people knowing how old the risk is, but most solutions would show you some history and would believe that to be pertinent information.
There will be instances of getting it wrong, but it isn't actually _that_ complicated.
Yeah, the argument apparently doesn't really grok how certificates are issued and why the changes exist.
Manual long term keys are frowned upon due to potential keyleaks, such as heartbleed, or admin misuse, such as copy of keys on lots of devices when you were signing that 10 year key.
Automated and short lived keys are the solutions to these problems and they're pretty hard to argue against, especially as the key never leaves the server, so the security concerns are invalid.
That's not to say you can't levy valid criticism. I'm not sure if the author is entirely serious either though.
p.s. Certbot and Cert-manager are probably fine, but they're also fairly interesting attack vectors
To be fair, the idea of the tools being standardized behind a single command like golang is nice, but this is largely what it all comes down to.
"Vite+ will be source-available and offers a generous free tier."
I'm also a developer ( sometimes ) and we need to eat. However, for me these tools are too low of a level of he stack to monetize, so I'll probably stick with my collection of free tools.
Evan You wrote on Twitter that source code will be accessible to everyone, but not under a full permissible license. He also wrote that they have no plans to sell any code licenses.
Every for-profit is subject to being sold to someone with different plans. If the license is not fully open, it's not smart to expect the licensing terms to get worse.
Selling access isn't really helpful there. The target group (companies) have to care about licenses at some point, while it will be free for OSS, individuals and the community.
That's not multi-master in the typical sense, it's sharding, and done correctly, you shouldn't have any write conflicts because each shard should be strongly consistent within itself.
Typically a strongly consistent (CP) system works by having a single elected master where writes are only ack'd when they're written to the majority of the cluster. The downside of this system is you need majority of the cluster working and up-to-date and the performance impact of doing this.
A multi-master system is generally ( AP ) allows writes to any master node, but has some consensus algorithm where it picks and chooses winners based on conflicting writes. It should be faster and more available at the cost of potentially lost data.
There are some systems that claim to beat CAP but they typically have caveats and assurances that are required. After-all, if you ack a write, and then that node blows up, how will it ever sync?
It's one of the few CI tools where you can test your pipeline without committing it. You also have controls such as only pulling the pipeline from trunk, again, something that wasn't always available elsewhere.
However, it can also be a complete footgun if you're not fairly savvy. Pipeline security isn't something every developer groks.