Our company has drastically downsized its dependence on Atlassian in the past month, we will be completely free in a few more. With the help of modern AI tools we've been able to replace their products with internal tools that are better tailored to our needs.
Why have every company vibe code their own semi-good bespoke tool when instead one company can handcraft the tool with optimisations much better than AI can ever dream of, and then sell that tool for a reasonable enough markup that the value proposition is big enough. Especially if the tool is open source open core, so companies can PR improvements they think will be broadly applicable.
Did they ever get around to fixing basic bugs like "Jira and Confluence use different markdown dialects"?
They've had a decade to address those sorts of obvious problems that bite 100% of the end users of their stuff, and apparently employed over 1600 people during that decade. That's 160 centuries of person time. I wonder what it was wasted on, if not making their fairly small core product suite usable.
I think we're going to see more and more incumbent companies with big moats and terrible products get replaced with vibe coded solutions over the next year or two.
No, they simplified it by cancelling almost all non-cloud instances and moved to being a direct per-seat SaaS, with (apparently) all the same bugs but fewer features.
I was talking to people I know about this topic and looking for obvious big success stories of vibecoding replacing enterprise tools like Atlassian I found they are very hard to find. At this stage I have no doubt that there are IT departments trying to displace SaaS products and re-engineer legacy systems, but it's probably too early to measure results.
And you're not likely to see any either, frankly, because you buy SaaS when you don't want to DIY.
It's easy to think of DIY software as "free" because you don't pay seat licenses, but DIY is expensive like a free yacht is expensive. It's a bottomless pit of money and time and upkeep.
Even if it's simple to implement, you still have to support it, update it, get people to use it, be on call if it tips over, teach people to use it, be forced to take it over when the person who wrote it leaves, etc, etc, etc
IT is a cost center and isn't staffed at the level of your revenue generator eng teams. You don't buy SaaS because you don't have other options, you buy SaaS to throw money at a vendor to take care of a problem for you, so your IT people can do the work you actually want them to do and not dick around rebuilding software that you already have.
If a thrown-together-quickly-with-left-foot tool is more or less as good as Atlassian's products, I wonder why they have been used in first place. Surely it can't be quality of the products. Nor price, as there are existing (even open source) alternatives that do the job well enough.
I think any company with some motivated developers and a budget for h/w or cloud could rebuild a good enough JIRA in a month. I don't see how Atlassian survives long term
Because you see the IC side of the Atlassian toolkit. The management side is much more expansive and this starts mattering when you are coordinating larger projects.
That said, if you are a smaller company, you absolutely could kill Jira pretty quick.
Jira isn't the product, it's the development platform that builds the product (which is a codified version of all the bad business decisions your company has ever made).
I hate Jira just as much the next engineer, but this is not at all accurate lol. The reason all ticketing systems are kind of terrible is they have to deal with a lot of complexity. Jira has waaayyyyy more features than you think it does.
Ticketing systems are not dumb CRUD apps, they're systems that build workflow engines. If you've never built a workflow engine, they're annoying but fine. Building an engine that can implement any special snowflake flavor of business workflow in a way that's reasonable with a reasonable UI is difficult.
And yes, you could write it for your special use case, but use cases change a lot and different groups need different use cases and the time you spend dicking around on building ticketing software that already exists is time you're not spending on shipping, and at the end of the day Jira is like $15/seat at sticker price, why are you bothering?
And that's why Jira is both terrible and still popular.
The flickering is solely a result of cost cutting in the power supplies of these LED lights. The problem is totally solvable with a constant current switching power supply. But the filtering circuitry adds cost.
The problem is that consumers usually cannot know this about a particular light (or a lot more) at the point of purchase, so even if you are willing to pay a premium for this you cannot.
I would pay a premium for longer life, and at least in some cases (e.g. lights I read by) for better quality. How do I do so? I would love to be pointed at sources of better ones (in the UK).
In the EU, lights have to be sold with a mandatory energy efficiency label. A lesser-known component of this is that this label includes a link to a standardised datasheet, which includes things like flicker metrics, CRI, chromaticity, and a measurement of the spectrum.
It doesn't fully quantify the light, but it's good enough to distinguish trash or even passable lights from actually good ones.
tl;dr: Just buy Philips UltraEfficient (I think these are roughly equivalent to the infamous "Dubai Bulbs"[1]) or Ultra Definition bulbs. They cost a little bit more but will probably pay for themselves over the years.
Buy name brands with a history of putting out decent bulbs instead of the Amazon alphabetsoup brands that won't be around in 5 years (although TBF some of my cheap BogAo bulbs are still going strong after 8 years). You can get a good feel for the light's "quality" by looking at the CRI and color temperature.
For CRI, anything 90+ is good.
For temperature, IMO around 3000k is the sweet spot. go higher if you want sterile operating room vibes or lower if you want super yellow/orange cozy hobbit hole vibes.
Heh, funny how personal preference differs. I find 3000K to be just slightly too harsh on my eyes, and prefer 2700K for everywhere except perhaps the bathroom mirror lights.
2700-3000 are honestly both fine by me. I just feel bad for people who go to Amazon, search "light bulb" and buy some random sponsored result that's 5000K
Hi thanks!
Sure, certainly!
I also want to eventually add some physics-based levels for fun, with like a box2D sim interacting with the circuits (with N circuit ticks = 1 box2D "tick"), or even little games on top of the circuit, but I need these tutorial campaigns first otherwise the step curve is way too high.
Unfortunately not really, but we've found (and used in production for a year) that Claude 3.5 is perfectly capable of identifying anomalies or other points of interests in very large sets of time series data.
Think of 100-200K worth of tokens formatted like this:
<Entity1>-<Entity2> <Dimension2> <ISO 8601 time +1> <value>
The only pre-filtering we do is eliminate "obviously non relevant" data, such as series where the value is completely flat the whole time, but this was done to add more data to the context, not because Claude struggled with it (it doesn't).
There could be a few benefits to what is proposed in the article, here are my semi-educated guesses.
1. Less dependent on local geology. Geothermal wells are well suited for hot, non-pourous (?) geology.
2. Might be cheaper. It can take years to drill the wells for a closed loop system (e.g. Eavor), less for a fracked geothermal well (e.g. Fervo). I imagine drilling a single borehole for this is way simpler.
3. Less water loss. Fracked geothermal well wells can be pretty lossy (20%?). If water supply is an issue your options may be limited.
200W at 300g is realistic for a modern BLDC motor. The article states that Maxon was the motor supplier so they likely used the EC-4pole series, I'm guessing it's one of these.
It's 30mm diameter to fit in a down-tube, 200W, and 300g. But just because it's 200W doesn't mean you have to run it at maximum capacity, there's no reason you couldn't run it at 5-50W.
'var' is JavaScript's older variable declaration construct. Variables created this way are live from the beginning of the function that contains them (or globally if there isn't one). So a block with braces (such as you'd use for a for or while loop body) doesn't actually restrict the scope of var `v` below:
console.log(v); // <-- v is a variable here, we can access its value even though it is only declared below
// prints 'undefined'
{
var v = 1;
console.log(v); // prints 1
}
console.log(v); // prints 1
You used to (and might still) see a workaround to recover more restrictive scoping, known as the "IIFE" (Immediately Evaluated Function Expression): (function () { var v; ... code using v here ... })() creates a function (and thus a more restrictive scope for v to live in) and evaluates it once; this is a sort of poor man's block scoping.
`let` and `const` were created to fill this gap. They have block scope and are special-cased in for loops (well, `let` is; you can't reassign to a `const` variable so nontrivial for loops won't work):
console.log(l); // <-- throws ReferenceError: l is not defined
{
// pretend the console.log line above is commented out, so we can reach this line
let l = 1;
console.log(l); // prints 1, as expected
}
console.log(l); // throws ReferenceError: l is not defined
// ^^ l was only in scope for the block above
Fun(?) fact: it's not technically true that const can't be used in for loops:
for (const i = 0; i > 0; ) {
console.log('this is stupid');
}
let ran = false;
for (const i = 0; !ran; ran = true) {
console.log('this is also stupid');
}
Our company has drastically downsized its dependence on Atlassian in the past month, we will be completely free in a few more. With the help of modern AI tools we've been able to replace their products with internal tools that are better tailored to our needs.
reply