cultural reviewer and dabbler in stylistic premonitions

  • 14 Posts
  • 126 Comments
Joined 4 years ago
cake
Cake day: January 17th, 2022

help-circle



  • How exactly do they hope to lock devs in github??? That’s absurd, there’s no way they can achieve that. I can always take my projects elsewhere and there’s nothing they can do to stop me.

    I can’t tell if you’re joking? If not, what do you think “lock-in” actually means?

    It doesn’t mean that it is impossible to leave, it means that there is substantial switching cost. And, that is certainly the case for github-hosted projects: all active contributors need to make a new account somewhere else, issues and discussions need to be migrated, CI workflows typically need to be rewritten, and good luck finding something that gives as much free compute for CI as github does. Yes, it’s easy to mirror a git repo onto another service, but github is much much more than just git repo hosting and each of their features have their own switching cost.

    Also, OP actually said “lock devs in” rather than “lock projects in” - I actually am forced to have a github account if i want to contribute to projects which refuse to move their issues off of it 😢 … and the difficulty in creating new accounts anonymously these days prevents me from contributing to several things (lemmy, for instance) which i otherwise would.




  • With the Mac SE and II, the switched to ADB, which looked like a PS/2 port, but you could daisy chain your mouse, keyboard, and other inputs like tablets or joysticks all into one jack in the back of the computer.

    The port looks similar - both are mini-DIN - but ADB has four pins while PS/2 has six.

    ADB was first introduced in 1986 on the Apple IIgs, and later was used in all Macs from the SE until the iMac. For the first few years there were two ADB ports, but in 1990 (maybe starting with the Mac IIsi?) they reduced it to one and started shipping keyboards with ports to daisy chain the mouse from.
















  • I started to python one and half week ago. So I’m still beginner.

    Nice work! Here are a few notes:

    The WeatherApp object has a mix of attributes with long-term (eg self.LOCATIONS) and short-term (eg self.city) relevance. Instance attributes introduced in places other than __init__, which makes it non-trivial for a reader to quickly understand what the object contains. And, actually, self.{city,lat,lon} are all only used from the add_city method so they could/should be local variables instead of instance attributes (just remove the self. from them).

    There seem to maybe be some bugs around when things are lowercase and when not; for example checking if self.city.lower() in self.LOCATIONS but then when writing there the non-lower self.ctiy is used as the key to self.LOCATIONS.

    The code under if rep == "1" and elif rep == "2" is mostly duplicated, and there is no else branch to cover if rep is something other than 1 or 2.

    It looks like the config only persists favorites so far (and not non-favorite cities which the user can add) which isn’t obvious from the user interface.

    Passing both location and locations into WeatherAPI so that it can look up locations[location] is unnecessary; it would be clearer to pass in the dict for the specific location. It would also be possible to avoid the need for LOWLOCATIONS by adding a non-lowercase name key to the per-location dictionaries that just have lat and lon right now, and then keeping LOCATIONS keyed by the lowercase names.

    HTH! happy hacking :)