thepratt

I go even further and use no volumetric measures. So grams for water, milk, etc. Having to read off the scale I can assure I have 500g water and not 520mL b/c I read the meniscus wrong.

I'll still convert for other recipies, water being the easiest to convert as 1mL should be 1g.

The grams for everything is a habit I've picked up from reading a lot of modernist recipes.

It's great that mostly everything is in grams, baking should be precise. It's hard when you read a recipie that uses cups without knowing the origin, as US vs not cups are different sizes (200mL vs 250mL). It would be nice if all measurements were in grams, baking soda and water included.

That's good news! Wasn't aware of the pin change for rocket.

Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.

Have you used sorbet on these codebases? I'd be curious if there'd be a benefit here in terms of maintainability.

Yes, you can apply patches from (mostly) any source. There'd be a slightly different markup/setup depending on how you popoulate your stackage/hackage - nix or http_archive (stack_snapshot). If you're modifying something from an upstream it'd be best to reference it as vendored, e.g. `@org//:package` and not the stack populated version `@stack//:package`. This is how you'd do it pulling from git directly (there's a whole lot more involved if this were to be done for a stackage package).

    http_archive(
        name = ...,
        build_file_content = """
          load(
            "@org//bazel:defs.bzl",
            "pai_haskell_library",
          )

          pai_haskell_library(
            name = ...,
            version = ...,
            srcs = glob(["src/**/*.hs"]),
            stackage_deps = [...],
            visibility = ["//visibility:public"]
          )
        """,
        patch_args = ["-p1"],
        patches = [
            "//dir:git-patch-file",
        ],
        sha256 = "...",
        urls = ["https://github.com/org/repo/archive/1.0.0.0.tar.gz"],
    )

When Template Haskell or multiple packages join the fray, compilation times can get quite high, quite quickly. This is more an experience with stack, as there are means for incremental caching to avoid full rebuilds when a top-level change is made - nix-build and bazel being a few.

It doesn't help that sometimes stack can't tell if it should rebuild TH or not - a long standing bug.

Using bazel as a build tool (on top of cabal) allows you to provide patches or modifications to found versions.

I don't have information to share on where to look, but some positions to consider relate to a11y. I've met and worked with some consultants in the past that their entire position was dedicated to making websites and apps more accessible - audits and on-going. He also did training for teams to bring them up on best-practice so the dev teams can do this proactively.

For the 2nd point: would you suggest a useEffect hook that has a dependency on the search key? With the current search() call replaced with an update of the search key state.

For the patent section, I don't understand how any of the 3 are worthy of a patent or were able to be patented. I'm not sure of timelines, but for the 3rd[1], isn't that what Instagram integrated ages ago with circles linked directly to a checkout - prior art?

[1] system to automatically match an item in an image, against its equivalent in a database with ecommerce links to purchase that same product.

Regularly, I donate to Battersea Dogs & Cats Home in London. Animals, I feel, are thrust into a poor situation and have less means to help themselves (not at all implying some people aren't also in this situation).

https://medium.com/@alex.lew/the-translator-pattern-a-model-... describes the pattern quite well in elm-first terms.

All the wording in https://discourse.elm-lang.org/t/native-code-in-0-19/826 seems to indicate the opposite. I'm not saying jQuery bindings are a good idea, but saying no to _everything_ b/c you don't want jQuery bindings is.

For anyone new trying to get into Elm (as a language/tool), I would look elsewhere. ReasonML, PureScript, TypeScipt, etc are all better featured solutions. Having said that, the article is well written and thorough for anyone wanting to take a look into Elm.

But there are massive problems with Elm itself which make it impossible to consider seriously. I have and still do use Elm in production, and went through the nightmare upgrade from 0.18 to 0.19.

1. Elm ports are not sound. Elm will tell you everything is good but doesn't do simple checks - as say PureScript does - to see if your port code actually exists or adheres to the defined contract. There are other tree-shaking issues, but Elm does not know and does not care about the js you've written.

2. Evan holds the naive view that everything can be rewritten in pure Elm and there's no reason not to. An overwhelmingly common use-case is 3rd party services or tracking libraries where it's impossible to re-implement; these apparently don't exist.

3. Elm applications, without a Redux-style (domain-specific to Translator) pattern, end up being horrendous spaghetti code of everything knowing about everything. Cmds and Tasks are a pain to work with when they should be interoperable in some manner.

For small embeddable or personal projects Elm is a fun tool. I don't see it being more than that until more community involvement is permitted - removing the dictatorship.

Is the launch related to Employ? https://remote.com/employ

Have not come across remote.com previously; a focused job board is useful, but Employ looks game-changing. (Note: I do not know what exists in this space already - if anything.)

I would suggest using a docker image with a mounted volume for development - there are alternatives, vagrant being one of them. As your production server will _most likely_ be a flavour of linux, this can help weed out "works on my machine" issues.

I wouldn't say the EU had knowledge to begin with. While GDPR was a step in the right direction, how poorly, and vaguely it was written created problems. GDPR isn't a concrete thing, but a high-level set of guidelines with no clear direction on what falls into each camp. This is why leading up to GDPR there were n consultancies, and articles vocalising "Our interpretation of GDPR".

Thanks for the template. I based my email off the back of yours.

It's got so much worse. Even within JIRA there's 2 different flavours: the backlog preview _new_ updated version, and the old horrid detail issue view version. Annoying doesn't start to describe it.

That's what Australia did ~2 decades ago. There used to be 1 and 2c coins; they were seen as useless, so they were axed. All prices are rounded up to the nearest 5c.

I have some python based lambdas for simple service/user story monitoring. The couple problems I have with lambdas, which mean I will _never_ use them for a proper application:

- The language choices available do not meet my needs - Impossible to create a prod-like setup; all our services run on k8, so mini-kube works great locally - You lose any sort of control over architectural decisions (for better or worse) - Poor code structure/quality/re-usability leads into poor developer experience. I enjoy most new technologies I pick up, all I got from Lambda was frustration.

I think the other more important path mentioned would be: "what happens in case of a ban/restriction?". Not with AWS, but we've previously had accounts locked/closed "accidentally" - thankfully they were non-mission critical.

I agree with your point, but to add an additional public example: the creator of GWAN was also rejected by the process http://www.gwan.com/blog/20160405.html

What I'm contesting is the assumption of the majority. There may be a small sub-set of programmers who will prefer the example, but until Avail's usage/interest is wide-spread such an assumption has no validity.

> But there are many career programmers who would rather say: > Print 1 to 10, as a comma-separated list.

No, I would not. Don't make assumptions on behalf of others.

Cheers, will have to investigate.

At that company we moved onto blossom.io for 2 months to see how we'd fit. It works well, more of what we want, but we had problems with updates/collaboration (visibility)/issue linking/etc. We worked actively with their product team, but feature delivery was a little slow - would reconsider going back though. We moved onto YouTrack afterwards - afaik, they're still there.

Where I currently work, we use JIRA.

Have always had problems with asana. It was always to limited for _my_ use-case (as a developer), and how other teams I've worked with did use it was awful. asana lacks granularity, or anything meaningful in terms of enforceable process. To me, asana is a glorified to-do list, not a project management tool. Their reliability was awful as well, having project-based outages for ~10 mins, multiple times a day wasn't leaving a good taste in my mouth.

There's PureScript to add to the list as well.