magic_lobster_party @ magic_lobster_party @fedia.io

Posts

0

Comments

401

Joined

11 mo. ago

I’m meaning more in the sense of a wearable head device developed by a big tech company. It’s heavily marketed as the next big thing. Many talk about it - both with anticipation and concern. And when it finally releases, it’s quickly forgotten about.

Hololens did the same.

Video game graphics seem to have reached diminishing returns at this point. Games are more expensive to make, but the end consumer barely notice any visual difference.

There was a time when having the best graphics in any video game was a selling point. People argued whether X360 or PS3 could produce best graphics. Now, nobody cares.

It’s Google Glass all over again.

Has any significant 3rd party apps been made for it?

Writing maintainable code is an art form. Like most art forms it can mostly only be learned by practice. So if you don’t have much experience maintaining long lived systems, it’s difficult to know what works and what doesn’t. Most universities don’t teach this as well, so it’s mostly something people learn in the industry.

Then I believe there’s also some aspect of pride in writing overly complicated code. It’s the belief that ”other people can’t comprehend my code because they’re not as smart as me”, when it’s actually ”I suck at writing comprehensible code”.

Yeah, computer science is the more about theoretical side of computation and the analysis of algorithms. For example, proving that a certain algorithm is a solution to a problem and has a particular time complexity. That’s more mathematics than practical programming.

I believe publishers already have good control over their prices. If they feel a game isn’t selling to the extent they wish, they lower the price. If it’s selling well, then they have no need to lower the price.

It’s market economy.

Probably Team Fortress 2. It was a comfort game for me when I studied university.

Haven’t played it in a great while now. Heard there’s a bad bot situation with it right now.

I’ve haven’t had a burnout (knocks wood), but the most toxic environment I’ve worked in had tight deadlines, unclear requirements and many last minute changes on features that ultimately didn’t mattered. Combine this with long and tedious release processes and narrow release windows. If a bug slipped through our (not so robust) testing process, it was difficult to fix it.

It felt like the priorities were all wrong. Instead of improving the product for existing customers and improve our release process, it was all about adding pointless features some ”potential buyer” asked for (they never bought the product either way).

Now I work in a much better workplace, thankfully.

We are number one!

It’s just example code to demonstrate the idea of the optimization explained in the article. I also based my code on the code used in the article (and made some major changes to better fit my attempt of explanation).

Basically it’s just an optimization of a double nested for loop. It’s a way to avoid running the inner for loop when it is known there will be no hit.

This is useful when we for example want to find all product orders of customers in a particular country. The way we can do this is to first filter all customers by their country, and then match orders by the remaining customers. The matching step is the double for loop.

Something like this:

 python

    
for order in orders:
    for customer in customers_in_country:
        if order.customer_id == customer.id:
            …

  

Many orders won’t match a customer in the above query, so we want to single out these orders before we run the expensive inner for loop. The way they do it is to create a cache using a Bloom filter. I’d recommend looking it up, but it’s a probabilistic cache that’s fast and space efficient, at the cost of letting through some false positives. With this particular use case it’s ok to have some false positives. The worst thing that can happen is that the inner for loop is run more times than necessary.

The final code is something like this:

 python

    
bloom_filter = create_bloom(customers_in_country)
for order in orders:
    if bloom_filter.contains(order.customer_id):
        for customer in customers_in_country:
            if order.customer_id == customer.id:
                …

  

Edit: this comment probably contain many inaccuracies, as I’ve never done this kind of stuff in practice, so don’t rely too much on it.

I haven’t been in a company that has gone bankrupt, but I’ve been in a few that struggled. The biggest problem is usually not the tech. It’s to align the product with the customer needs.

You can have the most advanced tech in the world. If it doesn’t solve anyone’s problems, no one will buy it.

but it will get tons of people that are interested in whatever you're doing to help for free

Will they though? It requires that some of the target audience are capable to contribute, which is rare in my experience.

Dopamine. Affirmation. Attention.

Although I don’t share that much on social media anymore.

I hate when coworkers tell we should do thing in a particular way because it’s ”better”. We try the thing and there’s no measurable difference. Well, it was a good idea in their mind, so it must be an improvement. Therefore, they insist it should be kept, even if it makes the code extra convoluted for no reason at all.

And yes. Profiling is great. Often it is a surprise where most time is spent. Today there’s few excuses not to profile since most IDEs have good enough profiler included.

Nice article. For the optimization related ones there’s a good rule of thumb: it’s not an optimization if you don’t measure an improvement.

I love Linux as well, but there’s always something you didn’t know about that breaks, and it’s up to you to figure out what broke and how to fix it.

I’ve had the problem for a while now that the audio is set to the wrong output after screen lock, and I have given up on finding a fix for it.

That’s how DRY is described in Pragmatic Programmer, where DRY was first coined. They’re clear that just because code look similar, doesn’t necessarily mean it’s the same.

I agree with the first point. Always go for clarity over cleverness.

I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.

Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.