HN user

stoplight

64 karma
Posts0
Comments13
View on HN
No posts found.

I've been toiling away for the past 2 years on a passion project. A native mobile app for the PWHL (Professional Women's Hockey League). It's privacy focused without ads and a bunch of features: https://pwhl.app

It uses flutter under the hood, with Kotlin and SwiftUI for native home screen widgets. A simple nodejs backend powers push notifications too.

I wonder how much of this is because (IME anyway) Tesla drivers are not very good. With all that tech it's easy to get distracted (there's literally a giant tablet looking thing for a console). It's also easy to think all the bells and whistles will do things for you so drivers are paying less attention because the car will beep and holler at them if things are going awry (except by that point it's too late).

I don't know. I am a woman who does not have those specific experiences. I happily buy stuff at Amazon, chat with relatives and friends on social media, and is active in some subreddits. I do know several harassment issues where I have received unsoliticed dick picks, been (verbally) sexually harassed, and received lots of creepy messages from strangers on the internet.

Both can be true at the same time.

Maybe believing women would help?

Am I missing something? The author states:

Try to find the answer to "which units are going to be started on next boot?".

Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up)

Also the other states:

Speaking of which, why is systemctl daemon-reload even a thing?

Because configuration changes while things are running. Otherwise we wouldn't need apache2 reload, nginx reload, haproxy reload, etc. Also, according to the man page:

After the units have been edited, systemd configuration is reloaded (in a way that is equivalent to daemon-reload).

As for systemctl edit, it allows you to add diffs to the unit file. For example, let's say I am using redis and I want to ensure it always restarts (for whatever reason). Rather than manually editing the unit file (which will have issues if an upstream change happens), I can simply use systemctl edit to add a diff for my change. This way I can still maintain compatibility with the upstream unit file instead of having to deal with potential conflicts. It's not so much babysitting the user as it is a potentially better experience.

and an even better one to read...and it's easy to understand which parts of the code do what

It's not always easy to understand (from Odersky himself https://gist.github.com/odersky/6b7c0eb4731058803dfd#file-fo...):

def toVector: Vector[B] = fold(Vector[B]())(_ :+ _)(_ ++ _)

To a Scala veteran, I'm sure that's easy to understand; to someone who's been learning the language (like me) it looks like gibberish.

I've also had to write code like this:

client.post(args).mapTo[Response].map(r => (r.success, r.serverException, r.unhandledException) match {

case (Some(response), None, None) => response

case (None, Some(serverEx), None) => throw serverEx

case (None, None, Some(unhandledEx)) => throw unhandledEx

})

simply because of the underlying api that other co-workers have built. When it takes you longer than 30 seconds to explain how a piece of code works to others, something is wrong.

All that being said, I do like the language; just not the compile times. It's also pretty close to ruby (with which I'm most familiar):

ruby:

numbers = [1, 2, 3, 4, 5]

numbers.select { |n| n >= 4 }

# [4, 5]

Scala:

val numbers = List(1, 2, 3, 4, 5)

numbers.filter(n => n >= 4)

// List(4, 5)

Pretty interesting. What does your uwsgi line look like? Mine keeps failing with "ImportError: No module named zmusic.login". I'm running:

uwsgi --socket /tmp/uwsgi-zmusic.sock --file /home/user/zmusic-ng/backend/zmusic -H /home/user/zmusic-ng/venv --callable app --processes 4