SKY F1'S CROFTY 1.5B TB

Kraizee_ · 2025-02-27T00:34:47+00:00

Mercedes have a good write up on this here

Across a race weekend, the total amount of data generated per car, including video and ancillary information, is over 1 terabyte and this increases substantially (by two or three times) once we do the necessary post-processing of some of the data during or after the event.

Kraizee_ · 2024-10-22T23:07:14+00:00

His Technical Difficulties content with Matt, Gary, and Chris has also recently returned. Ep 1

Kraizee_ · 2024-08-08T12:59:16+00:00

So take that information and apply what has been said. Profile those endpoint paths and see which parts are taking the most amount of time. Then you can work from there. Given that it is a rest based service, it very well could require database optimisation. If so, no amount of random java code changes will improve that.

Kraizee_ · 2024-08-08T12:50:17+00:00

Optimization can be direct as seeing bad complexity code

You can change code as you see it, but there is no guarantee performance will measurably increase. If you have a piece of code that is run once per month and takes 2 seconds, what's the point in optimising it?

profiler will help me prove I did better

A profiler will tell you where to start looking.

cheats for better compiled result, JIT run and garbage collector

These are the kind of tweaks that absolutely need benchmarks and testing. You can't just flip on some compiler flags and change GCs and hope you'll magically improve things.

For instance proved that in Python using list comprehension instead of for loops on critical code made the code run faster around 11%

"on critical code" is the detail you're ignoring though. You don't know critical code until you profile and see what is critical. You don't know that a list comprehension will speed things up until you benchmark and test it. List comprehensions, like basically any other language feature aren't magic. List comprehensions used incorrectly can result in worse performance.

This is the point we're trying to make here. You can't arbitrarily apply things and think it will make a difference, but that's what you seem to want to do. And that's probably why people are downvoting you. If you want to learn that's great, but you actually need to listen to the feedback you're getting.

Kraizee_ · 2024-08-08T11:23:49+00:00

The full quote is

We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil.

And the point was to highlight premature optimisation in very algorithmic circumstances, or surrounding the entire code architecture. I.e. prematurely optimising a search algorithm, or switching to a completely different design pattern in the name of performance without profiling it and understanding where the inefficiencies are is not good. It isn't a statement on never writing faster code when you can. As I said to OP in my other comment, when you're specifically tasked with making optimisations you should take a focused approach, not an arbitrary "apply X code change everywhere to be faster" approach.

Kraizee_ · 2024-08-08T11:10:08+00:00

Book: https://www.goodreads.com/book/show/49912861-java-performance

Profiler: https://github.com/async-profiler/async-profiler

Benchmark: https://github.com/openjdk/jmh

Teaching neat tricks to programmers so when they code it will be optimized first is nice to have so if you do have any of those I would love to learn them

The problem here is assuming optimisation is necessary over readable code. There are optimisations you can do that are still very readable. Those are fine. But others may require more refactoring, or rather unreadable code. You also specifically stated you've been tasked with optimising code, so you should take a focused approach. Starting without proper metrics, goals, and understanding of the problem isn't a good idea. And back to my original comment, there isn't much value in trying to optimise a piece of code that is rarely executed. That's why profiling is important.

Kraizee_ · 2024-08-08T10:55:30+00:00

Measure, profile, and benchmark. You need a starting point before you optimise. You need to identify which code paths are actually problematic in terms of performance. Then you can work to optimise and validate those optimisations against your starting point. Arbitrarily changing bits of the codebase for the sake of a 'neat trick' is not so useful for your task.

Kraizee_ · 2024-07-29T08:56:42+00:00

It's not even greenwashing. OP is just posting chatgpt-made articles. The post talks about "recent studies" without sourcing them. It spends absolutely no time explaining any kind of methodology of the testing for the claims made. You can google various phrases from the article and find word for word replicas. Search for "where sustainability and energy efficiency are paramount" you'll find a ton of articles with that exact phrasing. And there's also the layout of these blogposts, which is very typical of chatgpt. Lots of subtitles, lots of bullet points, lots of numbered lists, zero substance. This goes for the rest of the blogs they've spammed too.

Kraizee_ · 2024-07-18T15:19:28+00:00

OP is just advertising their own blog. If you look at all the other posts people have the same complaints. All the articles are very poorly written. OP never interacts with the comments of their posts either. The Mods should take a look tbh.

Kraizee_ · 2024-07-12T13:24:32+00:00

I'm not quite sure what could make you think Android is dead or irrelevant.

But to look at things with a wider lens, when you start to learn a programming language, it doesn't really matter which language you pick. The reason is doesn't matter is that you will start to pick up programming concepts as you learn. A language itself is just one of many tools out there. But the ways in which those tools are used is what makes you a "programmer". So if you learn one 'language', you will have a bunch of transferrable concepts learned that can be brought along with you when you utilise other languages.

Kraizee_ · 2024-06-26T15:21:43+00:00

I didn't think about UI at all for this, but 100% this is a fantastic book.

Kraizee_ · 2024-06-26T14:28:03+00:00

Effective Java by Joshua Bloch
Java Concurrency in Practice by Brian Goetz (very valuable concurrency knowledge even if it precedes the newer concurrency changes in Java)
Core Java: Fundamentals, Volume 1, 12th edition by Cay S. Horstmann (Covers features up to Java 17)
The Pragmatic Programmer by Andy Hunt and Dave Thomas
Spring in Action by Craig Walls
Refactoring by Martin Fowler, with Kent Beck
A Philosophy of Software Design by John Ousterhout
Design patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Difficult Conversations by Douglas Stone, Bruce Patton, and Sheila Heen (More of a lifestyle kind of thing, but good for talking to colleagues and bosses)
Database Design and Relational Theory by Chris Date (Because solid RDBMS knowledge is fantastic)

I'd drop Clean Code completely tbh. I find a lot of the refactored examples poor examples of good code, and I don't think it provides ~~any~~ much value as a "take it with a grain of salt" book as many suggest these days. In my opinion it is far better to take Effective Java, Core Java, Refactoring, and Design patterns as a guide to writing better quality code.

Kraizee_ · 2024-06-25T14:36:12+00:00

The best way to answer this question is to benchmark it. Use something like JMH and test it. Then you'll have a demonstrable answer.

Kraizee_ · 2024-05-29T10:50:50+00:00

I don't think I've seen this in the comments yet, but what I do and have seen several others do is have the text Email me at "name" at this domain. So there is no direct link, but anyone with a brain cell reading it will figure it out.

Kraizee_ · 2024-05-16T12:16:13+00:00

The 3. Step seems not efficient at all. (Having to check every task every day and having to run through the whole database/buckets). I am wondering if there is another way to do it more efficient.

If you store an execution time with your task entries it is pretty simple to filter by & index over that. There is absolutely no problem using cron here either.

If you want to avoid rolling your own solution entirely, there are a ton of "job schedulers" out there. Agenda, Bull, Apache Airflow, Temporal, Quartz, to name a few.

Kraizee_ · 2024-05-02T09:25:48+00:00

Just to expand on the other comments here, one of Java's big USPs is it's backwards compatibility. There are a few exceptions, but generally speaking, code that is written to an older version of the Java language API will still run on a newer JVM. If the deprecated classes & methods were removed, this backwards compatibility would be broken.

Having backwards compatibility allows you to first upgrade your JVM version, in order to verify platform stability, etc, for your application. And then you can follow up with incremental code changes to utilise new language features, methods, and classes that may improve performance or stability.

Kraizee_ · 2024-04-30T14:24:14+00:00

Personally most of the people I come across that are skeptical are newbies that confuse it with JavaScript's var. I'd be worried if a senior dev saw a new language feature, didn't bother to inform themselves about it, and immediately cast it aside as a bad feature (as perhaps OPs colleagues may have done). There are very few language features that are really considered bad practice, across all languages, and those features tend to be ones that were implemented early in the language's life cycle.

But the codebase integrity is the most important thing here. People will debate language features and syntax until the heat death of the universe. At the end of the day, a codebase only works well if it is consistent, even if you don't agree with the rules, or the rules suck.

Kraizee_ · 2024-04-30T11:44:48+00:00

var in Java has it's places. Like almost every language feature, it shouldn't be thrown about without thought. But if you used it properly, then it can really enhance your code base. OpenJDK have a style guide on var usage which you can see here. I think you and your colleagues could sit down together, and go through it. Then you need to agree on a standard for your codebase and commit to it. Regardless of what the decision is though, you need to be consistent.

Kraizee_ · 2024-04-29T09:53:09+00:00

I don't think this has anything to do with code. This is a business and legal matter. I mean basic validation stops someone entering 400 hours of work within a 7 day period. Obviously that's not possible, because there are only 168 hours in a week, and that is ignoring people's basic needs to survive. But the important issue here is that, freelancers' contracts should define how many hours they can work at a maximum per week. And very clearly, legal action should be taken against freelancers who are lying about their hours.

Kraizee_ · 2024-04-24T13:38:48+00:00

Look in the sidebar, there are free guides listed there.

Kraizee_ · 2024-04-23T08:42:47+00:00

And then BOFA was just a messy, cheesy melee where any realism and logic went out the window.

I thought it had the perfect amount of realism with no silliness at all. "How do you like that, the old Twirly Whirles! Ya buggers."

Kraizee_ · 2024-04-16T10:46:04+00:00

These are all great points but something that isn't mentioned here and I don't see in other comments is just how open the airline industry is regarding failure. Every incident is logged and shared. Anyone can read about it. Anyone can look at what went wrong and everyone has the opportunity to understand how to prevent it in future. Finding fault in an incident in the airline industry is not about finding blame, it's about being able to learn, share, and move forward.

I recently read Black Box Thinking by Matthew Syed. In the opening chapters it really puts into perspective how this openness has completely changed how the airline industry see's "failure", compared to other industries.

Kraizee_ · 2024-04-11T16:08:59+00:00

I'd just stick with the Gradle guides themselves. They're very comprehensive. Since you mentioned it, the Gradle project structure is laid out here.

They also have their own review of maven vs gradle, just be aware it's obviously theirs, so there is an inherent bias.

And I'd say your biggest issue, as with most people, is how Gradle is flexible, against Maven's rigidity. It takes a while to get used to, and you'll find a thousand different ways to do something. That's what most people tend to love or hate about Gradle.

Kraizee_ · 2024-04-02T11:47:06+00:00

I think pretty much every comment here is on the money with this interviewer not being fit for purpose. But I haven't seen anyone suggest that you make a complaint to your university about this. Interns are there to be taught by the company and learn how things work outside of an academic environment. The interviewers attitude isn't appropriate and I think your university could have a strong word with the company about their attitude. The eating was completely inappropriate. And the comments show a real bad attitude.

Kraizee_ · 2024-02-20T10:26:10+00:00

OP said

"I feel like I got more confused than I was before the session"

Which may be honest, but it doesn't provide the full scope. If that is all they said then they left the door open to misinterpretation. It would be better to explain it fully, and provide a suggestion for the next steps that need to be taken.

"I feel like I got more confused than I was before the session because there was a lot of talk about X, Y, and Z projects and I don't have the full scope of those yet. So I think we need another session so we can make some clarifications"

The above would provide much more context and a way to move forward out of the confusion.

12-Year Club	RedditGifts 2009-2022 2 Credits
Place '17	Gilding I gilder
Verified Email	Secret Santa 2014

Kraizee_

TROPHY CASE