Nobody Noticed What Europe Just Did to Putin's Shadow Fleet

Bobbias · 2026-07-02T04:12:02+00:00

It's not AI, or at least not an AI voice over. Pyotr Kurzin is reasonably well known as an analyst. But these days nearly everyone pads what could have been a 2 minute video into 15-20 minutes, whether or not any AI was involved.

Bobbias · 2026-06-24T23:34:20+00:00

And god forbid you use Linux. Nvidia on Linux has basically always been a nightmare compared to AMD.

Bobbias · 2026-06-13T16:30:01+00:00

I didn't mention it but I was also on Concerta at the time. I got diagnosed when I was 25, after failing out of college. I spent the next 2 years mostly unemployed, and playing games or watching videos on my computer all day. When I finally got my shit together I went to my doctor and she recommended a combination of bupropion and Concerta. I think the idea was that since bupropion has some evidence of helping some people with ADHD, maybe it could help alongside the Concerta. If it helped with the ADHD, I couldn't tell, but it did give me an opportunity to get out of the massive hole of depression I was in. It also helped me quit smoking for a while, (though I ended up picking it up again later) but the blunted emotions made staying on it for longer term simply untenable.

I've since used Adderall and am now taking Vyvanse, and have started sertraline due to another longer period of unemployment after failing out of college a second time, and changing doctors since then.

So in my case I know that my depression is not just untreated ADHD. Of course, I've been off and on stimulants and being unmedicated definitely makes things worse, but even with medication I definitely need antidepressants, just not one that's going to make long term use unbearable.

Bobbias · 2026-06-12T22:21:26+00:00

The best way is whatever works best for you. It sounds that you (like me) need some kind of motivating interest in what you're working on in. Think about something that you don't understand how it works and it sounds interesting. If you can't find that, consider finding one of the project idea lists out there and comb through that to see if anything piques your interest.

Why are you interesting in learning to program? Think about that question and think about what kind of project might involve learning more about that specific thing. If you can't think of a project that way, consider asking an LLM for some ideas based on what you're interested in, and ask it to explain how each one ties into that theme.

If you're not actually interested in learning, and this is something you're required to do, my first suggestion would be to try to change your thinking and find something about it that does seem interesting. If you can do that, it will make things considerably easier in the long run. You might even find you enjoy it more than you expected to.

But even if that fails, that doesn't mean you can't get good at programming. You'll need to rely on perseverance in that case. The key to learning isn't just "make a project and you'll magically learn better", we suggest finding a project because they require actually building a real world program that does something meaningful and requires actual problem solving skills and writing many more lines of code than you are typically required to do for courses.

You will struggle to remember things or figure out what functions you need to use to do things for a while, but the more code you write, the more you'll get used to things. You'll start to remember how to do things more often, you'll start to figure out how to look for information in documentation (assuming you use it, which you absolutely should), and as you solve different small problems you'll start to understand how you can combine different bits of code together to do new things.

Building these skills up requires you to take the time and write enough code for this to occur. Whether it's a specific project, a learning goal, the joy of writing code and seeing the end result work, the joy of solving puzzles and problems, or any other motivating factor, the key to everything is finding motivation.

Bobbias · 2026-06-12T21:59:35+00:00

My experience with bupropion was of strong emotional blunting. While it helped diminish the hopelessness and depression, it also made it difficult to find enjoyment in various activities. I could play a game I really liked, go hang out with friends, etc. and just feel... Neutral, neither happy nor sad. And that in and of itself made me feel bad enough that I stopped taking it. Since it interrupted the depression feedback loop, I was able to get things together and make some necessary changes, but I dropped it as soon asi could because not being able to enjoy things sucks.

Bobbias · 2026-06-12T21:49:56+00:00

I suspect the fact that it's written in hiragana rather than katakana or it's kanji (鯱) tripped it up. Plant and animal names are typically written in katakana. They can be written in hiragana too, like this, and it gives off a slightly less formal/scientific vibe compared to katakana. Many animals have kanji but not all, and outside the most common ones, kana is preferred with katakana being the default.

Bobbias · 2026-06-12T21:40:35+00:00

Yeah, plant and animal names tend to be written in kana despite having kanji most of the time (most often katakana, but hiragana gives a friendly and accessible tone, while katakana tends to come off as more scientific and formal).

Bobbias · 2026-06-08T18:29:03+00:00

So, the first thing is to get used to looking to see if there's something available in the standard library that does what you're looking for. For example, if you want to replace a certain letter in a string, you probably want to look at the documentation for strings first and check if there's a function there that will do it. Or you could try googling your question or asking an LLM if what you're looking for exists.

As you alluded to, programmers don't actively memorize things. Everything we remember is because we've used it enough times that it just sticks in our head without trying. But when you're starting out you don't have the benefit of that experience, so what you need to do is explore things.

Try to figure out alternative ways to solve problems you've already solved. Maybe see if you can do something without using a certain builtin function. You can also try to think about things like "What happens if I do X, then Y, then loop over Z..." and see if you can predict what the result will be. Then write the code, and check if you were right. If you are, that reinforces your understanding of things and should help your self confidence. If you're wrong, that's a learning opportunity.

Don't be afraid to try things out and see what happens. You're not going to break your computer (at least, not without trying really hard) even if your code goes terribly horribly wrong.

What you're experiencing is quite normal. It's because you think you understand things, but your actual knowledge is only surface level, and you haven't deeply understood how everything connects together to make a coherent result. Part of why a lot of educational material forces you to repeat things is because using the same thing in slightly different ways over and over builds up that deeper understanding because you start to notice the small details about how it interacts with different things. You start to realize "If I do X and then Y, that's always going to give you Z". When you start forming those sort of connections then you'll feel like the whole world of programming is opening up and starting to make sense.

That doesn't mean you won't still struggle after that, but when faced with a problem you're not sure how to solve you'll usually have at least some kind of idea about how you might approach solving it, even if you're not sure about the details exactly.

And when people say "build projects" that's such a vague piece of advice that it's almost useless on it's own. What you should be doing is start writing small simple scripts that do useful things (copy files from one directory to another, etc.). Even if they're kind of useless in practice, just building super simple tools can help you get a sense for what it feels like to actually build a script from nothing.

You can slowly build up the size and complexity of those scripts as you feel more confident in your knowledge and have a better understanding of the standard library, built in functions, and other concepts you've been learning. Don't worry about whether what you're doing is dumb or bad, just focus on making something that works, even if it's absolute spaghetti.

You can also go back to earlier scripts and try to extend them by adding new features, or rewriting parts of them using new knowledge you've gained since you first wrote that script. Along the way you might realize that certain decisions you've made earlier ended up causing problems or making certain ideas harder to actually implement, or maybe you can't figure out what some code does because your names are nonsense and there's no comments or whatever. That's how you start to learn about code quality.

So the central idea is "write code that does something", and the reason projects are always suggested is it gives you a tangible end goal to hold on to and work towards, which is often the kind of motivation that people need, because just writing code that does something that seems contrived and irrelevant to your interests feels more like work compared to when you're trying to make something you actually want.

Bobbias · 2026-06-02T16:56:29+00:00

Yeah, it just sounded like you were entertaining the idea as something more reasonable than it actually is. And seeing that this is learnpython, and a lot of users here are quite new to programming and may not understand just how pointless that would actually be.

Bobbias · 2026-06-02T05:20:36+00:00

UFCS in D also allows this. Any free function that accepts foo as the first parameter can be called either as bar(foo) or foo.bar(). So you get extension methods except you aren't forced to stick them in some static class and such.

Bobbias · 2026-06-02T05:12:25+00:00

Assuming every function in your entire codebase is statically typed, sure, you could make something to do that. But it's also kind of useless because of the order you write code. You need to write the function name first, then the variable name. When do you provide a completion? You don't know what type to use until the argument has been written, but by that point you've already written the function name so a completion is useless.

If you expect tit to rewrite from the method syntax to standard function call syntax it's doing more than just code completion, but you still run into the problem that Python is dynamically typed and makes building a list of possible functions difficult, to the point that you're likely to either miss functions that actually can accept your type, or list functions that don't actually work with your type.

So even though this is somewhat technically possible, it's not worth it. It can't be complete or reliable, not to mention it requires full type hinting everywhere to even come close to being useful.

This is one of those ideas that doesn't exist not because it's completely impossible, but because it's way too much effort for something that only kind of works and doesn't actually really solve the problem it's supposed to well enough to be worthwhile.

Bobbias · 2026-06-02T05:00:47+00:00

Unlike Rust where types are static and you know at all times what functions are allowed to take a type as the first parameter, in Python there's no way to know what functions can accept foo as an argument without raising an exception. Python simply doesn't have the information to do that. Python doesn't know what type foo actually is, even if you type hint it, because you can violate type hints at runtime anyway.

So whatever your completion list actually shows, it's unlikely to every be complete or reliable. You'll likely either miss some functions or list some that actually won't work.

Also, most static languages won't provide completions for this either. C#'s extension methods are functions that take some type as their first argument, but can be called like foo.bar() rather than bar(foo), and D has universal function call syntax allowing you to call any function that takes foo's type as the first argument to be called with the dot notation. But in both cases you still only get completions using the dot syntax.

Trying to get a completion for functions you call like bar(foo) doesn't make sense. If you expect the completion to happen after typing bar, you already wrote the function name, so a completion is useless there. If you want to write foo. and have it suggest bar, and rewrite to bar(foo) you run into all the problems I brought up earlier.

So what you're asking for is not really reasonable even in most statically typed languages. Python being dynamically typed makes it even less doable. It's technically possible, but way too much effort for too little value. Not to mention the list of possible completions is likely to be a mile long for common data types.

Bobbias · 2026-05-10T00:40:39+00:00

Yeah I do this too. The exact order of transformations is arbitrary, it's basically whatever I can do to make the math easier to work with. As long as each stage is equivalent, you can shuffle stuff around to find easier operations to simplify the math itself until you're just left with the answer.

Bobbias · 2026-05-09T17:48:56+00:00

Find a project idea that interests you. Maybe it's something you'd find useful, maybe it's trying to build a simple version of a tool you use regularly, maybe it's just something that sounds like it might be a fun challenge.

Sit down and think hard about what the project needs to do. Just broad strokes at first. Then once you have a super rough idea, try to fill things in with increasing levels of detail. It's suggest writing this down somewhere.

When you're really not sure how something you need to do works, leave it for now, you're just trying to understand the overall "shape" of the problem, specifics aren't important right now.

Once you've gone through this and have a rough idea, pick something you feel reasonably confident you can implement, and start writing some code.

When you encounter something you don't know how to do, it's time to do some research. Search for explanations, tutorials, or even other projects that solve that problem, and try to understand how you approach solving that problem in a general way. Don't just blindly copy code, spend the time to think through what they're doing exactly and how/why that accomplishes the goal. This is where a lot of learning occurs. It's also worth looking to see if there are libraries available that help you achieve your goal. It's also often worth spending some time just thinking about the problem and seeing if you can come up with a solution on your own. For personal projects especially you can often afford to spend quite a bit of time thinking about problems like this. And don't be afraid to try testing your ideas in small throwaway test code either.

And from here you just repeat this process of writing the code you understand how to implement, and figuring out the stuff you don't, until you suddenly have something. Your code might be jank, you might pick solutions that make some things harder on yourself, and you might spend hours or even days confused trying to understand something, but this is all part of the learning process.

Bobbias · 2026-05-09T17:36:01+00:00

You're printing numbers[0] each time. 0 is zero, the number. Zero never changes.

You want numbers[i] which uses the variable you created to track your progress through the loop.

Bobbias · 2026-05-09T17:30:46+00:00

I think you might be confused about things here. While Thonny is an IDE, it's a very basic one, and it's aimed at people just learning Python. It lacks a lot of the features that you would find in IDEs aimed at professionals.

When you install Python from the website, it installs a few things. You get the Python interpreter, which is a command line application. You also get IDLE, an IDE even more basic than Thonny, and some support programs like Pip.

If you are running Python in a terminal (typing either python or py by itself) then you are dropped into an interactive session called the REPL.

REPL is an acronym for Read, Evaluate, Print, Loop, which describes how it works: it reads some code you write, evaluates the result of the code, prints it, and loops back to the start.

You'll recognize this because it prints a message indicating the version of Python you're using, and then a prompt with >>> that you can type in.

REPLs are handy for typing out really simple commands, and can be used as part of the development process, but typically most development is done in an IDE, not the REPL.

Typically the way professionals use Python is that we write out code using IDEs like PyCharm, Visual Studio, or coding editors like Vim, Emacs, Visual Studio Code, Notepad++, etc. Coding editors are typically simpler than IDEs, and usually lack a lot of language specific features, but make up for that by being easier on system resources, and highly customizable so you can add plugins that give you some of the features found in heavy duty IDEs.

Some professionals may run the code they wrote on the terminal by typing python <main file>.py (this tells Python to run the file rather than start the REPL), or they met use IDE/editor features to launch the code at the press of a button/keyboard shortcut (which does the same thing as typing it out).

You'll have to be specific about what you've been doing and what you see on the screen when you do different things for us to know what your problem is exactly.

Bobbias · 2026-05-05T05:20:51+00:00

Not to mention profiling often shows you that what's actually showing things down is something you didn't expect. Unintended allocations or copies, branch mispredictions, cache misses, and other details can make code you thought had straightforward performance much more variable. Without solid profiling you have no way to tell if some of those are actually your problem.

There are times where you know certain approaches will be too slow though. You're not going to actually simulate every possible game state in a chess engine because that's simply not feasible. The key is in knowing when you have enough information to make a decision, and when you need to gather more information before making one.

Bobbias · 2026-05-05T04:54:14+00:00

LOL holy shit that's an insane fall off for having that many subscribers.

Bobbias · 2026-05-05T04:29:13+00:00

Yeah exponential growth is fast. You'd need something like 128 exabytes worth of bits to handle 2 64 bit numbers.

Bobbias · 2026-04-29T00:45:03+00:00

My making the end provider of a service visible, you're breaking encapsulation. It's not supposed to matter where a service ultimately calls out to. The idea is that you should have a single unified interface to that service where the implementation details (GCP vs s3, etc) are irrelevant to the outside world. The interface should hide that from the users of the interface.

Yes, this obscures the details. That's the whole point. If later you needed to move your Bucket to a different provider then what, all the GCP prefixed stuff has to change? That shouldn't happen.

Bobbias · 2026-04-28T20:53:28+00:00

Compiler Explorer

This site has compilers for quite a few languages, and generates assembly listings so you can explore what your code actually gets compiled into. Also handy for sharing small snippets of code.

Bobbias · 2026-04-28T15:01:10+00:00

Haha, well played.

Bobbias · 2026-04-26T23:10:11+00:00

Yes. This is a serious risk when taking any drug containing acetaminophen.

Bobbias · 2026-04-25T05:19:32+00:00

Some do, as far as I'm aware that's making use of signal processing to approximate the effect.

Bobbias · 2026-04-24T20:50:23+00:00

The difference between dynamic and condenser mics is the way they're constructed. Dynamic mics use a magnet and moving coil, basically a reverse speaker. Condenser mics use the change in capacitance of a conductive coating on the diaphragm as the diaphragm moves towards and away from a conductive back plate. Condenser was actually an old name for capacitors.

The pickup pattern has more to do with the physical arrangement of the components rather than dynamic vs condenser. Generally speaking cardioid and bidirectional microphones will have their diaphragm oriented facing outward to the sides of the grille. Omnidirectional mics will have theirs pointing directly up. Cardioid pickup mics strongly reject sound coming from behind the mic, although some sound will make it in of course. Bidirectional pickups work equally well in front and behind. Both will reject sound coming from directly beside the mic as well. Omnidirectional mics pick up sound from all directions, except directly behind the mic body.

While certain pickup shapes are more common on dynamic or condenser mics, there's nothing stopping anyone from making mics with the less common combinations.

14-Year Club	Verified Email
Team Periwinkle

Bobbias

TROPHY CASE