Skip Navigation

canpolat

@ canpolat @programming.dev

Posts
412
Comments
125
Joined
3 yr. ago

  • Say you could solicit a notable figure in technology, who would you want to lurk on this instance?

    Jump

  • By "lurking" I understand: they would be here reading and voting but not engaging otherwise. In practice, is it any different than not being here at all?

    If by "lurking" you mean that they would be here posting under pseudonyms and asking me if I would be able to identify them... Then it's a more interesting question. But I don't think I would be able to identify them from their style.

  • Software engineers hate code

    Jump

  • What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service.

    We only get this if we do microservices correctly. That's more or less the whole point of my comment. In many cases, teams rush into splitting their monolith into smaller chunks and call it a day. Without proper monitoring, orchestration/choreography, service boundaries, tooling, etc. microservices will drag a team into territories where they will lose control.

    Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code [...]

    No, I don't believe that. However, I also don't believe people who write spaghetti code will start writing better code just because now they are writing smaller components. If the team has good coding hygiene, they will produce good code whether it's monolith or microservices. But you have a point. If we are talking about components that are 200LoC, it's more difficult to produce spaghetti (or easier to recover from it). I'm not sure that's the norm, though.

    As a final note: I'm not saying microservices are bad, or monolith is better than microservices. I'm just trying to introduce some nuance. I have been part of a microservices transformation and I think it was successful. But we met with many challenges along the way that were not immediately obvious from the beginning. To quote one of the pioneers of microservices architecture:

    Don’t think of adopting microservices as flipping a switch; think about it as turning a dial. As you turn that dial, and have more services, you’ll hopefully have more opportunity to get the good stuff out of microservices. But as you turn up that dial, you’ll hit different pain points as you go. (Sam Newman, Monolith To Microservices)

  • Say you could solicit a notable figure in technology, who would you want to lurk on this instance?

    Jump
    • Linus Torvalds
    • Kent Beck
    • Dylan Beattie
    • Ian Cooper
    • Simon Brown
    • Martin Fowler
    • Daniel Terhorst-North
    • Sam Newman
    • Andy Hunt

  • 100% code coverage is near-meaningless - but is there a good measure to use?

    Jump

  • I think this is a good rule-of-thumb in general. But I think the best way to decide on the correct coverage is to go through uncovered code and make a conscious decision about it. In some classes it may be OK to have 30%, in others one wants to go all the way up to 100%. That's why I'm against having a coverage percentage as a build/deployment gate.

  • I built an easy-to-use bot to auto-post from Youtube

    Jump

  • I see that you have the following line in your bot:

     typescript
        
auth: @me.secrets.lemmee,

    Does that mean you are storing the JWT in your secrets? Doesn't that mean that it will expire after some time? Wouldn't it be better to get the JWT before performing the action? Something like this: https://www.val.town/v/canpolat.getLemmyJwt

  • Removed

    White Box Testing

    Jump

  • Most of the time 100% code coverage is just a waste of time.

  • Software engineers hate code

    Jump

  • Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.

    Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.

  • I built an easy-to-use bot to auto-post from Youtube

    Jump

  • Thanks for sharing. This is a great way to write simple bots without dealing with hosting.

  • Removed

    SQL Aggregate Functions

    Jump

  • Is WordPress with ActivityPub Plugin a good setup to host my own technical blog?

    Jump

  • Did you take a look at write freely or other blogging software with native ActivityPub support?

  • Email vs Capitalism, or, Why We Can't Have Nice Things - Dylan Beattie - NDC Oslo 2023

    Jump

  • Thanks for sharing this talk. I watched it a few day ago and thought of sharing, but then forgot about it. As pointed out in the video description: "Email is too big to change, too broken to fix... and too important to ignore." The bit about the first marketing email was interesting (video timestamp) and is relevant for our times.

  • GitHub achievements that did not make the cut

    Jump

  • I would definitely have the "Vital Contributor" badge if it existed.

  • Validating or verifying emails

    Jump

  • Recently, I have seen web apps that requires an email address, then does the validation by sending an email to that address and only then allows the user to proceed with registration. That's probably the only sure way of validating an email. Users may still use disposable email addresses or short-lived aliases. But I think that's acceptable.

  • Non-general purpose posts

    Jump

  • I don't know what the mods think about your arguments, but I agree that posts that already have a community should be posted on their respective communities and not here. There may be exceptions where certain language/tool related thing may be relevant for a larger audience, but those are probably rare cases.

  • Sudo

    Jump

  • Do people use git alternatives?

    Jump

  • Git is definitely dominating the landscape. The fact that it is free software plays a big role. There are alternatives, but they are unlikely to gain much adoption. They may provide slightly better UX or marginally more comfortable flows, but it's not enough to replace Git. Not to mention, most developers don't even really care about which SCM they use.

  • The one thing you cannot do in object-oriented programming but you can in functional

    Jump

  • Video description:

    In Object-Oriented Programming, objects are instances of classes and they encapsulate behavior and state - that is what every textbook on OOP is teaching. However, there's a subtle limitation in OOP when it comes to dealing with changes in the state of these objects. We often try to mitigate that limitation by applying the State design pattern, but that adds extra complexity and potential confusion to downstream components, especially when using Object-Relational Mappers (ORMs).

    In this video, you will learn to recognize the fundamental limitation of Object-Oriented Programming and how Functional Programming (FP) offers an inverse perspective. Through immutability and transformations of values, FP tends to make state transitions explicit and predictable, leading to a more straightforward way of handling the issues that would otherwise be too large a burden for a corresponding object-oriented model. This requires a shift in thinking and can introduce its own challenges and learning curves. It is a fascinating topic, shedding light on the fundamental underpinnings of OOP and FP, and their practical implications in software development.

  • You might as well timestamp it

    Jump

  • Good point. However, approaching this problem from "YAGNI" point of view is a bit misleading, I think. If you are not going to need the timestamp, you shouldn't add it to your code base.

    In my opinion, hastiness is the culprit. When a property appears to be a binary one, we jump to the conclusion to use a boolean way too quickly. We should instead stop and ask ourselves if we are really dealing with a situation that can be reduced to a single bit. The point raised by the article is a good example: you may want to record the state change as timestamp. Moreover, in a lot of the cases, the answer is not even binary. The values for is_published may be, "Yes", "No" or "I don't know" (and then we will be too quick to assign null to "I don't know"). Underlying problem is that we don't spend enough time when modeling our problems. And this is a sure way of accumulating technical debt.

  • The Password Game

    Jump

  • You can change the captcha by refreshing it using the button next to it