mullsork

Ouch, my bad!

In the series Babies by Netflix some of her research on this topic is covered. Season 1 Episode 4 "First Words."

Today the hitbox and damage taken is all dependent on things that do not include aim i.e. if you're one game away from losing, you will likely hit jumping pistol headshots across a map and if you're 4 v 1 trying to close a round, the first person to engage will likely die and you will win with 2 or 3 left standing.

What? Who told you this?

I do not permit a woman to teach or to have authority over a man; rather, she is to remain quiet.

For anyone curious.

Usually get a new monitor and a new PC every 4 or so years.

Maybe you're not quite the average consumer that OP has in mind? Maybe you are, I don't know. Either way it's unsustainable and ridiculous that the _average consumer_ would need to replace something after 4 years when it COULD be built to last.

Refactoring our supabase/postgres repo to improve components and utilize nix for building, packaging, and conducting high-level infrastructure tests.

Looks like they do mean nix!

Are those schools privately or publicly funded?

JS doesn't have any useful built-in way to deal with success/failure, other than exceptions. We use Boxed[1] for this:

  Result
    .fromExecution(() => schema.parse(input))
    .mapOk(parsed_input => /* */)
    .mapError(parse_errors => /* */)

I would hazard a guess that `parse` is a function introduced long ago, and `safeParse` came afterwards. (Safe as in "do not throw an exception")

[1] https://github.com/swan-io/boxed

I open up hanamirb.org at least once per week since the announcement of v2 back in November 2022. Pleasantly surprised to see this new view layer announcement today!

Anyone using Hanami 2 in production that would care to share their experience?

IIRC that's what oneOf is for. i.e. a discriminated union / sum type. My experience with oneOf is that tooling support for it is terrible.

SQL MERGE looks great! I hope I remember it when the time comes, instead of writing 3 separate queries.

edit: Postgres docs on MERGE: https://www.postgresql.org/docs/15/sql-merge.html

Congrats! It would be interesting to hear more about the rewrite, 18% code reduction is significant. Have any of the contributors written about it somewhere?

For some reason this does not work with the Vimium browser plugin. Otherwise, very cool!

Seems to me like it's an advertisement for shipit

This looks great! Sign up for the free trial was pretty slick. I'm not sure how well known Klarna is outside of Europe (I know they launched in the US), but that would be my preferred method of payment. Or.. anything but Paypal (and giving my CC information)

I like that definition: the code might be fine as far as code itself goes, but it's still slowing you down as you iterate on the product. Decisions that were somewhat right at the time have slowly started go wrong as new ideas, requirements, and knowledge arrives.

On backends that comprise a database and an API layer on top I find that the sweet spot of speed + iterability can be found by deconstructing the product into its atomic parts. This boils down to modelling the database so that is as close to "reality" (as seen from a business/legal perspective rather than the product's perspective.) as is comfortable.

Reality is somewhat immutable (compared to a product.) Deconstructing (not just necessarily normalize) the API entities into small parts that reflect some "real world idea." The product is an abstraction of "reality" and that abstraction may change, but the underlying parts do not.

Of course once performance comes into account things may be different, but speed is rarely an issue when we start.

Momo Finance | Senior Fullstack Developer | Berlin, Germany Remote | https://www.getmomo.de/

At Momo we want to impact the lives of millions of people and free them from the burden of rent deposits. We want to change the real estate sector for people for good through the power of technology.

Tech stack: React, Node, Postgres

Read more here: https://www.notion.so/Senior-Full-Stack-Engineer-698f87db5d7...

UPDATE: We are now also hiring FE/BE developers who are not comfortable in a full stack role.

Backend: https://www.notion.so/Backend-Engineer-44d0295e191d48c3af27d...

Frontend: https://www.notion.so/Frontend-Engineer-50e6887a33214c7a96b0...

I wasn't thinking about lunch, but that makes sense. It's not as strict or drastic here in Berlin. For a 9-6 office job, I'd say people leave for lunch between 12-13.

What I'm thinking of in the Nordics, or Finland especially since I haven't worked in the other ones, are the two coffee breaks that are part of the work day. I've worked in construction and the aforementioned tech internship, and this is roughly how the day looks (offices tend to start one hour later):

- 06:50: arrive early, banter, coffee - 07:00: day beings - 09:15: first 15min coffee break - 11:30: lunch break - 14:15: second 15min coffee break - 15:30: day is over

I may be off by 15 minutes for the coffee breaks, it's been over a decade since I worked outside of the tech startup bubble.

Not sure how things are in Finnish startups, probably slightly different? I miss these "natural" breaks though. On the other hand, I do enjoy having my coffee while working as well. :')

My experience outside the Nordics says somewhat different.

An appreciation of and desire to be in nature is part of almost every society on the planet

I would rephrase that as "An appreciation of and desire to be outside in great weather with friends is part of almost every society on the planet." I'm sure there are plenty of exceptions, but I've met few people who are willing to, for no purpose other than to be outside, go outside in hard wind or light rain. The idea of "go get some fresh air, you'll feel better" doesn't seem to resonate well.

fika

What makes the fika culture unique (we have it in Finland too) is not that you decide to go grab a coffee during the work day. For me, it's that _everyone_ takes a break at the same time to have coffee. I only did an internship in tech back home, but even there we would all take a break at 9:30 to sit down, have a coffee, and talk about whatever we came up with.

When I hear non-Nordics talk about Nordic culture I get the feeling that they're very focused on what individuals do, whereas the whole point is what people collectively do.

Or if you're in Berlin, you lose your internet connection inside the large city as well. Seems to have improved greatly in the last two or three years though.

  Location: Berlin (want to relocate to Stockholm)
  Remote: Yes
  Willing to relocate: Yes
  Technologies: C++, Ruby, JS, Postgres, React
  CV: https://www.dropbox.com/s/app10r56os3yx4z/CV%20June%202020-min.pdf?dl=0
  Email: In CV
  Available: Now

Some of the languages I would be excited to work with but don't yet know include C++, Rust, Haskell, Elixir.

Although I still enjoy working in the web space, I would be very motivated to learn something brand new such as embedded programming.

Congrats to the Haiku team! I recently started testing it out, hoping to contribute soon, and it's pretty neat. I last played with it 10 years ago, and it feels a lot more solid today. Really looking forward to what's in store for R2 when R1 is released!

  Location: Berlin
  Remote: Yes
  Willing to relocate: To Sweden
  Technologies: Ruby, JS, SQL, C++
  Résumé/CV: https://www.dropbox.com/s/app10r56os3yx4z/CV%20June%202020-min.pdf?dl=0
  LinkedIn: https://www.linkedin.com/in/emil-ahlbaeck/
  Email: e.ahlback at gmail.com

I've worked in all parts of web development, and am passionate about transition towards native applications or systems. In particular I'd want to work with C++/Rust, but I'm not biased against any languages.

There are ads on Reddit already. I only ever use their website with an, but I get ads on the iOS app.

I've been seeing a significant rise in the usage of gold/silver/platinum lately, used heavily for banter on r/soccer (and for rewarding quality content as well.)

I think it is a good thing JSON is limited in what types it supports. Otherwise it would contain so much type bloat while at the same time still annoying someone somewhere because his type is not supported by JSON.

I wish it had a few more capabilities, but since JS doesn't then JSON won't.

If you are able to pull your data from the database and process it in a programming language of your choice, you can write a custom serializer that takes a tsrange and spits out some JSON, e.g. a JSON array with two items [start, end], which you then can pass on to a client that understands your JSON format.

I can definitely do that. My case though is aggregating and serializing into JSON in postgres and loosing type information due already on the query level.

Very fair to say that this logic ought to exist on the application level, I suppose.

You can opt out of loading the library code for views/mailers/etc. Not sure if there's a way to skip the routing layer though. I'm sure you're aware of that already but just in case, you can skip loading the entire framework.

My biggest gripe with joining and aggregating to JSON is JSON itself. The project I'm working on is dealing with timestamp ranges which of course can't be serialized to JSON.

Although I'm not working with SQLAlchemy (or Python) I presume it has the power to serialize a TSRANGE into a native Python range (if it has that) as well.

I'm curious if anyone has ever found some way around that, I feel like it isn't possible UNLESS there's some data type than JSON available that I could aggregate with.

Still a proposal and experimental, stage 3.

The case studies articulate the difference pretty well.