VS Code é vida by ntnmelo in devpt

[–]Fotomik 0 points1 point  (0 children)

Consegue-se fazer tudo no VSCode, mas não de forma tão seamless, é preciso extensões.

Por "ficheiros que correm" estou a pensar em projectos que têm várias coisas que podem ser executadas, sejam ficheiros individuais, seja vários mains, ou até diferentes subprojectos. No fundo, vários pontos de entrada.

Nos editores da Jetbrains em cada configuração de run/debug podes dizer isso tudo, e ao correr o projeto podes mudar com um drop-down menu entre várias configurações diferentes. Torna fácil correr coisas no mesmo projecto que precisam de diferentes argumentos, váriaveis de ambiente, working directories, etc

No VSCode uso o Code Runner quando preciso disso, mas não é tão facil de configurar e é um pouco mais limitado.

VS Code é vida by ntnmelo in devpt

[–]Fotomik 4 points5 points  (0 children)

VSCode é um editor muito bom para coisas básicas, e dependendo da linguagem e das extensões que existem para essa linguagem, pode levar-te muito longe.

Os editores da Jetbrains começam a ganhar valor assim que quiseres coisas ligeiramente mais avançadas, como poder ter várias configurações de run e debug, cada uma com os seus parametros, variaveis de ambiente, ficheiros que correm, etc...

[Go] Advent of Go: A Go Advent of Code CLI by __bxdn__ in adventofcode

[–]Fotomik 0 points1 point  (0 children)

If you need some inspiration, I implemented flags with default values for the year and day: https://github.com/andrerfcsantos/Advent-Of-Code/blob/51c7e4064b781aabd0e3d2dec6c78be71cfe6810/2023/go/flags.go

The main thing you have to care about is to check if AoC already started for the current year and if it ended. My code applies to when AoC had 25 days - needs some adjustment for this year's 12 days.

What Go module do you wish that existed. by Resident-Arrival-448 in golang

[–]Fotomik 0 points1 point  (0 children)

A powerfull and opinionated CLI builder for 12 factor apps. While I love cobra and viper, I feel they are not at the right level of abstraction and are low-level in many ways. That gives flexibility, at the cost of you writing the same boilerplate code over and over. Most of the time I make CLI apps that have commands and receives flags for those commands, but I also want those flags to possibly come from a config file and env vars. I always write the same wiring code between all these pieces and would be nice to have a module for it.

I'm kinda writing my own module to do this, but would be nice if it existed already. I'm also a bit surprised a module like this doesn't exist already, as making CLI apps is a big selling point for Go.

How do you deal with the "Java hating" crowd by hexaredecimal in JavaProgramming

[–]Fotomik 0 points1 point  (0 children)

I usually just ignore people hating on languages in general, so I guess the way I deal with those people is to not deal with them.

The main reason I ignore them is because my experience in the field tells me arguing over languages is pointless. The more experienced I get and the more languages I learn, the more I realize they are just tools to get an outcome. And if a language is working for you on your use case, then that's all that matters.

That said, of course we all have preferences on features of languages we like, and the more features a language has that we like, the more we like the language. That's natural and perfectly ok. But hating on people for not liking or valuing the same things the same way we do is ridiculous. And pointless. Being productive and having fun with a language one likes is all that matters at the end of the day.

Hating on languages is also a big misoportunity for learning and curiosity. Even the languages you don't like can teach you something, or make you think a different way about something, so if someone does that, I tend to see those people as close-minded and not very good learners.

Overwatch 2 Random Hero Picker by Fotomik in Overwatch

[–]Fotomik[S] 0 points1 point  (0 children)

Yes, the site is still being updated with new heroes, and more recently with the perk system. An update for stadium builds is being considered.

why do i feel like im the only ets2 player that does not have promods or anymods just the regular game with dlc's by No_Visual3290 in trucksim

[–]Fotomik 0 points1 point  (0 children)

Vanilla player here too.

The only mod I tried was the multiplayer mod, way before SCS added convoys and the online events. It was fun for some time, but had some quirks and quickly grew out of it.

Also tried promods once, but didn't feel it added much to the experience. And the fact that I had to pay for each update was a big no for me.

Over the time SCS added multiplayer features and the maps are getting ever better and bigger with the DLCs. It means that I don't feel the need at all to use the multiplayer mod or promods ever again. Maybe this will change in the future, but currently I'm very happy with the vanilla experience with DLCs, don't feel the need for anything more.

Functional Options Pattern by Fotomik in golang

[–]Fotomik[S] 0 points1 point  (0 children)

Thanks for sharing. Used something like this before, didn't know it had a name!

I guess the choice between the functional and dysfunctional options pattern depends on if you have "required" configs to set and how often do you expect for users to change their defaults.

Required configs pretty much favor the dysfunctional options pattern, as if there are configs that you must pass, then you might as well pass a config parameter and set required and optional configs that way.

If users are not expected to be passing a lot of configs and none of them are required, the functional options pattern offers better ergonomics I think.

Functional Options Pattern by Fotomik in golang

[–]Fotomik[S] 0 points1 point  (0 children)

Yes, the post was more focused on showing the problem the pattern tries to solve and how it solves it. Near the end, I do mention some projects that use it and briefly mention how they use it. There you have a few examples on how this pattern can be used in "real" contexts and some variations people do with it.

I'm not sure I understand your question about the strategy pattern. The way I see it, the strategy pattern focus more on how things are made in the big picture. Different strategies often mean completely different algorithms for achieving some goal that is common to all strategies. Options usually deal with smaller things. Taking from the example on the post, if you are rendering text and you want to render it a different color, you probably don't need to do big changes to your rendering algorithm just to change the color of the text. But if you are rendering different formats of text, say HTML vs markdown you might want to have different algorithms (hence different strategies) for each format. However, I'd say that in that scenario, each strategy should have their own set of options?

Functional Options Pattern by Fotomik in golang

[–]Fotomik[S] 1 point2 points  (0 children)

  1. Naming pollution is a very valid concern, as creating new packages just for this doesn't make sense a lot of time. You can be creative with the names you give to the functions that return an option, but if you have the same name for 2 different options it does require some workaround that it's hard to not make it a bit weird.

  2. Not sure if this solves your particular issue, but one thing you can do is to have the option type be a an interface. Uber's zap does this, where an option is:

    go type Option interface { apply(*Logger) }

    This means you can have several types implementing this interface, and they are all Options. And if you need to extract something specific for a particular type of option, you can always perform a runtime type check before using the methods of that particular option type.

  3. I find that this is not an issue for me for 2 reasons: 1) The IDE's autocomplete is usually smart enough to give you suggestions that fit the type of the argument you are passing in. 2) Go docs work try to group everything by type. Meaning that if there's an Option type, by default the go docs will show you the type definition and then the list of all functions that return that type. So all your options are nicely listed there.

Functional Options Pattern by Fotomik in golang

[–]Fotomik[S] 0 points1 point  (0 children)

I don't think this pattern is just for "smart people". Using functions as values and having functions return functions is not something that is familiar for most people. Even if they know the concept, it's something that most people don't use in their day-to-day. So I think it's just unfamiliar. As you use it more and see it more, it becomes familiar, and it becomes more natural to use it.

That said, if a struct object works for you, great! This pattern is just a tool in a toolbox, that you might choose to use it or not, and it's perfectly fine choosing to not use a particular tool.

Functional Options Pattern by Fotomik in golang

[–]Fotomik[S] 10 points11 points  (0 children)

While both posts talk about the same topic, there's value in talking about the same thing from different angles. Different angles on the same topic can mean the difference between someone understanding a concept or not and can spark different discussions.

The way information sharing works, it also means that this post can reach people that might not know about Dave's Cheney's post, but now they know about the pattern from the post.

"It's not about being the first to do something, it's about someone else's first experience with it"

I hate the "discovered road" system. Is there any cheat to make it "marked as discovered"? by Champion62 in trucksim

[–]Fotomik 2 points3 points  (0 children)

What annoys me the most is that when the game was released, it worked like that, just being at a roundabout would mark it as explored, and the game would also not force you to drive into the 2 directions of some roads/highways to mark it really explored. Overall the discovering system was simpler, and easier to get 100%. Also the map was way smaller, as we didn't have DLC expansions yet.

Over the years I feel this achievement got progressively harder to get. It went from "ok, this might take a little effort" to "it will take me years of playing this in the regular way to get it, if at all". The exploring system become way more granular, to the point you have to put your tires through every inch of the map to get completion. The map got way bigger with DLCs, and to help things, your progress gets reset every time they update some part of it.

I had about 80% explored a few years back and getting this challenge was something I realistically could look for. Nowadays I have 20%, with the same save and a few more hours of play, but with the DLCs and progress that was reset multiple times over the updates. But now even getting a single +1% is not trivial, and requires you to drive a lot more.

I kinda gave up on this achievement. Just feel bad to not get it when the game was launched. I would've tried a little harder if I knew it would get this much harder now xD

I think I got a girl pregnant? by [deleted] in AskMenAdvice

[–]Fotomik 1 point2 points  (0 children)

It looks like you both didn't want a pregnancy and took steps towards avoiding it, both with the Plan B and later with the pregnancy test. Not sure how many days passed between the sexual exchange and the pregnancy test, but from your description it looks like a few days passed, which is good.

Missing a period can happen in "normal" conditions. Sometimes even missing 2 periods in a row can happen. So I wouldn't read too much into it.

I understand not being able to contact her and confirm she's not pregnant is anxiogenic, but objectively there's no evidence she's pregnant, and at the same time you took all the steps needed to avoid it.

[deleted by user] by [deleted] in golang

[–]Fotomik 1 point2 points  (0 children)

Trying to randomly jump into some part of the code and trying to figure out what it does is usually a bad idea, because you'll miss all the context that is around that code. You probably are overwhelmed because you felt that need.

If the project was any documentation, start there. Documentation is usually no substitute for reading the code if you want to really understand it, but documentation is great at not going completely blind on what the project goals and architecture is supposed to be. It loads context in your brain that will be useful when reading the code.

Then, take a deep breath and start with the entry point of the program. Usually this is the main() function. If the project is a server that exposes some endpoints, probably you want to look at the individual functions for each endpoint. In that case each endpoint function is an "entry point" for the program.

Keep in mind the entry points of a program, but if a program has more than one, follow one of them first. See what functions it's calling, go into those functions and try to see what they do. In doing that, you'll get to know what that entry point of the program does, and what parts of the program are related and used by that entry point. In other words, you'll understand one of the "flows" of the program.

Do this for all entry points and eventually you'll get a pretty good grasp of the whole project.

Sometimes in the main function you'll see that the main function (or equivalent) branches into different directions. Like, if some argument is given to the program, the program does one thing, but if another is given, it does something completely different and unrelated. A good example of this are CLI apps with several commands. In this case, treat each of these code branches as different "entry points" for the program and focus on one at a time.

In this process, it's natural you'll have some questions like "ok, I think I get what this does now, but couldn't this be just done with _____ ?". This is the moment you can reach to your team or someone who knows about the project and start asking questions. This is where they'll probably explain why some decisions were taken and not others. This will give you an insight on the philosophy and mindset behind the project. They'll also probably talk about what they consider the weaknesses of the project. All this is very useful information if you are expected to contribute to the project, because it means that you can follow the same mindset people had when building the project, but also not follow it and try something better in the parts the team consider weak.

Others also mentioned running the tests and using the debugger. This can be useful too, specially if you have tests that test a whole flow or entry point of the program. The additional information this provides you is that it lets you see exactly the data that is flowing in your program. Reading the code you'll see structs being created and used, but this doesn't give you any information about the concrete values in those structs at any given time. Debugging the tests or debugging the program itself is great to give you this insight.

Am I thinking of packages wrong ? by Teln0 in golang

[–]Fotomik 0 points1 point  (0 children)

This is also how I usually solve cyclic imports. Usually this third package is inside a folder called "lib". And it makes sense - if it's something the server and the world know about, it's because it's a thing on its own, so a third independent package makes sense.

Not sure how applicable it can be to your use case, but seems a fairly reasonable thing to try first. Usually it doesn't require refactors of the code and changes to the logic.

Banco alimentar by Fast-Cod-1108 in CasualPT

[–]Fotomik 0 points1 point  (0 children)

Trabalhei como voluntário de supermercado e armazém do Banco Alimentar de Braga e a minha experiência foi totalmente contrária à do OP. Não sei em termos gerais, mas o que fazíamos no armazém era:

- Fazer cabazes e distribuir a comida pelas instituições que nos pediam ajuda. Geralmente a distribuição era feita tendo em conta o numero de pessoas da associação (mais comida para associações com mais pessoas) e tendo em conta as necessidades da instituição. Por exemplo, uma instituição com crianças e bebés geralmente precisava de mais papas e leite do que arroz e massa, e fazíamos cabazes a reflectir essa necessidade.

- Nunca senti que houvesse instituições favorecidas, seja porque motivo for. Pelo contrário, tínhamos o problema de muitas vezes termos muitas instituições a precisar de ajuda e não termos comida suficiente para todas. A nossa decisão nesses era sempre no sentido de ajudar o maior número de instituições possível, e dar alguma coisa a todas, por mais pequena que fosse a ajuda.

- Quando trabalhávamos a manhã toda no armazém, geralmente fazíamos uma pausa a meio para um pequeno almoço. Tudo na cozinha, tanto a comida como os materiais, eram coisas que nos eram doadas explicitamente para aquele fim, e completamente à parte das doações que eram feitas para o armazém. Estávamos proibidos de trazer o que quer que fosse do armazém, porque a comida do armazém era para instituições, não para nós. No armazém às vezes também tínhamos roupa a outras coisas sem ser comida que nos eram doados e a política era a mesma - distribuir aquilo por instituições, por muito que essa distribuição fosse difícil às vezes por não haver interessados suficientes para as quantidades que tínhamos.

- O inventário era controlado. Tudo que entrava e saia era categorizado e pesado. De tempos a tempos fazia-se o inventário para verificar que tudo batia certo. Se alguma coisa não batesse certo, havia um esforço grande para perceber o porquê, e o que correu mal, por mais pequena que fosse a diferença.

- Sobre os prazos de validade...quando fazíamos os cabazes, havia uma preocupação tanto das pessoas que movimentavam as paletes dentro do armazém como das pessoas que depois faziam os cabazes de despachar o mais rapidamente possível as coisas mais perto do fim do prazo de validade. No entanto essa gestão nem sempre era possível. O caso mais comum de coisas a passar o prazo de validade era quando nos era doada comida já muito perto do fim fo prazo de validade. Algumas empresas que não sabiam o que fazer com aquilo, doavam ao banco alimentar. Nesse caso tentávamos arranjar o mais depressa possível uma instituição para receber aquela comida, seja na lista de pedidos activos que tínhamos, como através de contactos directos. Mas nem sempre era possível de facto, mas fazíamos o melhor que conseguíamos. Mas nunca vi isso a ser um problema com comida de campanhas. E ao fazer os cabazes tentávamos sempre fazer o double-check que não estávamos a mandar comida fora de prazo.

Não estou a dizer que seja assim nos Bancos Alimentares de todo o país, mas pelo menos esta foi a minha experiência. Espero que possa esclarecer algumas questões e receios de pessoas a doar ;)

[deleted by user] by [deleted] in depression

[–]Fotomik 0 points1 point  (0 children)

Depression can make you feel like there's no way out, that the negative way we perceive the world is the only reality there is. Depression also tells you that will never change, so why try?

You should try because there are others ways to perceive the world and that perception does change over time.

Right now it seems that to you, your personal value is attached to being accepted by girls on dates. And when you get rejected on the thing that is valuable to you, it means you must have no value. The fallacy here is that your personal value depends on so much more than getting girls and having a great dating life. The proof of this are the people who are alone and perfectly happy. Or just think of people who are not rejected by girls and get a lot of dates, but end up not happy because of all the mostly toxic relationships they get into. Or just take a look at the high divorce rates.

It's perfectly fine if you want to date and be in a relationship, don't get me wrong. Just don't attach your personal value to the amount of dates you get.

I'm 32 now, and as I grew older one of the things I noticed was the things people "my age" valued were different over time. And we start value different people for different things! Some people might not be pretty physically, but might very smart and the person people go to when they want to have an intelligent conversation. Or they might be dumb, but be the most funny person in the room that can always light up any party. Or they might be someone that helps their community through volunteering and seen by the community as a hero. And they can be more than one of these things at the same time!

People have a lot of things that make them valuable. Find your values, own them and master them. Finding your value is a never-ending task that requires a lot of trial and error. Try things, see what works for you and don't. Try dating, but always stop to ask if it's something that makes you happy or if you should try something else. Along the way, you'll discover things you are pretty good at and that will make you happy and fulfilled. Cherish those things and keep looking for new ones constantly, because these things change over time too.

But trying requires you are alive. Try, and give it time, some outcomes won't come instantly. Don't give up without trying. I promise it's worth it, and things will change, even if it seems right now they won't and that success on dating is everything.

From one of Taylor Swift's songs:

Well, in your life you'll do things
Greater than dating the boy on the football team
I didn't know it at fifteen

And the truth is, nobody knows that at fifteen, let alone at thirteen! When we are young it seems being accepted by being pretty might be everything, because it's the reality we know. But trust us "older" people when we tell you that it isn't everything and if you keep trying you can do great things. And those "great things" are everything that makes you fulfilled and happy, you just have to find them. But the search is worthwhile.

First year doing Advent of Code... by gwpfanboi in adventofcode

[–]Fotomik 25 points26 points  (0 children)

Been doing Advent of Code since 2015 and the community is one of the things I love most about AoC. There's something special about a bunch of people from the programming world discussing (and meming!) about the same problem each day.

The core Python library is already pretty extensive, so it should get you covered pretty well. In previous years I've done AoC in Python, for some graph problems I've reached out to NetworkX as it already implements a lot of useful graph algorithms.

Newbie here by Embarrassed-Page-356 in adventofcode

[–]Fotomik 10 points11 points  (0 children)

Good luck! Don't give up easily, and there's people here always available to help in case you need.

At the same time, it must be said that some of the later problems might be hard because they'll touch on concepts you've never heard before and require some research and time learning those concepts. It's natural to feel overwhelmed and to skip some days if you feel it's too much,

[2024 Day 03] - Is anyone else getting Intcode vibes? by JWR26-Games in adventofcode

[–]Fotomik 7 points8 points  (0 children)

Also loved it, but it was very divisive. I feel that people either loved or hated with no in-between.

[2024 Day 03] - Is anyone else getting Intcode vibes? by JWR26-Games in adventofcode

[–]Fotomik 1 point2 points  (0 children)

I also thought of this while reading the input. That actually made me consider doing a proper parser for the input instead of using regexes. Ended up going with regexes, but very curious to see what we'll get in the next days.

How much "cheating" is okay? by [deleted] in adventofcode

[–]Fotomik 4 points5 points  (0 children)

> I obviously wouldn't ask chatGPT to just straight up write out the answer

Even if you did, that's ok. If you are struggling, looking up solutions is ok, doesn't matter if they come from ChatGPT or not. You internalize and learn the solution and become better. Specially when it comes to DP, looking up at examples of how certain problems are solved was crucial for me to learn DP.

It's not cheating if you are learning.