mackwic

I can vouch for Tuple, it's an excellent app. Far better experience than Discord or Google meet screen sharing.

Give it a try !

It's not that hard for any competent organization: document what PII you store, who has access to it, and what you do with it. Also have an internal procedure to scramble someone's PII on request.

If you have a direct or indirect contractual relationship with the person whose PII you are storing, there is nothing more to do. If you don't, ask for permission and store the timestamp of the authorization.

That's all. Really it's that simple.

Just so you know, it's a common practice in the US. As europeans, we are almost required to open LLCs in your states, do a joint venture with a local US company, and hire US persons to sell to US people.

It's a matter of fact that the EU is still more open to commerce from US, than the US is with the EU.

I think you highlighted the main issue: it's not sexism, it's simply misplaced.

Would it be 4 women and 4 men, it would still be out of context and not right. I don't know if it's more jackass or more redneck, anyway it's not something that should be encouraged.

moul: care to comment about how things are at scaleway and how's the roadmap going ? Is VPC the next item on the list ? :)

Congrats on the steady advance anyway. It's been a pleasure to use scaleway so far.

Just quit my last startup because it didn't worked with my associates. We made an ISO certified medical wearable: a connected insole with pressure sensors with its associated software suite.

Interested by complexes challenges: Kernels, Compilers, or any complex applications, always open to learn new things.

  Location: France
  Remote: No
  Willing to relocate: Yes
  Technologies: C, Rust, Ruby, Ocaml, Backend (RoR, Node.js), DevOps (Linux, Debian, CoreOs, CM, AWS)
  Résumé/CV: https://fr.linkedin.com/in/thwickham
  Email: mackwic+hn @ gmail

You can take a look at Rust. The authors are really careful to design an elegant C++ replacement, with no troll features and zero-cost abstractions.

> with dailymotion now close to death

Not close to death, it's just not a unicorn. They can IPO whenever they want as long as they claim a correct valuation.

thanks for your detailed answer. It's an interesting stack ! Using docker for integration testing seems like a good idea.

> Although perhaps writing code in OCaml has made me somewhat overconfident in my code

Many Ocamlers could be caught of overconfidence. It's hard to understate how ML typing help seeing the data flow.

Excellent insight, thanks for your clarification.

You can't reasonably use functors of all your code dependencies (function arguments mostly).

I am amazed to see how the MirageOS team used this, but this method cannot be used for all the code.

> As a side note, I usually see mocking being used to test badly structured code.

You could want to mock just because you are inspecting particular stack frames in a specific call stack, trying to reproduce a bug. It happens.

> Did you try to use OCaml and run into a bunch of difficult problems?

Yeah, I am a long date contributor and user of ocaml for little projects (mostly compilers and AIs). But not professionally.

> It's been years since I used OCaml and I don't know anything about OPAM so I'm also interested in the answers.

Opam is Bundler done right. It manages ocaml toolchains and packages dependencies. It's easy to pin a specific version or publish your own.

A setup oasis + ocamlbuild + $editor could go quite far. After that, it will depend of how you works and what you are developing.

> Like, testing is basically just checking a bunch of if statements. You can use fancy frameworks that color your tests red and green, but other than that kind of thing, what's the actual problem? Why do you say testing in isolation is particularly challenging with OCaml?

That is a very interesting question that deserve a blog post on its own. But I don't have the time nor the patience to do so, so let it be the HN comment.

> Like, testing is basically just checking a bunch of if statements.

Wrong ! There's multiple kind of "if statements to test";

-1- I want to test that `my_inner_fibo(0, 1) == 1`. This is unit test. Basically a transcript of the technical specifications into assertions. This is the easiest test, the most verbose, but it's also the kind that test the least.

-2- I want to test that `UserModule.retrieve_orders(user, command)` makes the good calls. This is integration testing in white box, which test that the API contracts between you inner interfaces are respected (which is also part of the technical specifications). I don't find it very useful but it's better than nothing when you can't do more.

-3- I want to test that, with a given state `user`, and `command`, when I call `UserModule.retrieve_orders(user, command)` I get exactly this object. This is integration testing in black box. This is useful to find errors in inner logic a group of modules (but you don't know immediately what gone wrong). As the call stack could be very large (and so the scope of what you are testing), you want to reduce the moving parts and replace some of the modules with trivial mocks. Integration testing in a black box test a lot of things and is very useful to find bugs.

-4- I want to test that a call to `$./my-binary ctl command --flag=true` have a specific behavior. Could also be a network request to a server, a message to a deamon, a click on a GUI... Anything exterior to the program. Here we test the behavior. This is what the user will use, that's why it's functional testing. This could break often (in the case of a GUI) or not (in the case of a CLI binary). You should always do functional testing if you respect you users a little.

All these kinds of testing have different requirements, and some need a perfectly controlled state to be created. The issue is not in the conditional testing, but in the setup this perfect controlled state, which sometimes need to make the code believe it use the good module, but you gave him a stubbed one which does trivial work, or signal you when something happens.

I don't know any simple way to spy on functions without using the MirageOS design which heavily use Functor injunction. It's quite an academic way of doing it.

Now you have a very smooth ocaml worklow:

- you create and manage the build of your project with Oasis which call ocamlbuild nicely

- Opam works great with ocamlfind to manage the dependencies and the toolchain you use

- OUnit has backgroud workers for parallel testing

- Merlin and ocamlc annotations do wonders in term of semantic completion

- utop is an excellent toplevel with colors, completion and integration with ocamlfind so that you can load dependencies inside

All these technologies have greatly improved in the past 2 years, which is a really short span compared to the age of Ocaml.

F# is an excellent technology, and inspired some of the recent Ocaml developments (we still look at ActivePattern with envy).

I saw some pieces of F# in the FinTech here and there, I think Microsoft could do a better job at marketing it because it really has great potential in the .Net ecosystem.

Thanks for your detailed answer and congrats for successfully maintaining libguestfs.

> I'd also say the killer advantages of OCaml for me are: Easy calling into C, and compiles to a native binary.

Very true. And Ocamlbuild makes wonders.

> I'm always very amused when people say OCaml can't work at "enterprise scale"

Yeah, you will notice that quotes that show you shouldn't take it too literally. ;) (also I have no doubt that Ocaml can work in a business. I just saw no one speak about it appart Jane Street, so I am curious)

What I was meaning that "a team with a hierarchical organization, not-ony-geniuses, and more than 4 people". Few of the serious Ocaml projects (if any) fall in this category, which is common for all businesses.

About the testing tooling, I am well aware of the state of these technologies. I even contributed to some of them. Sorry but it's light. It doesn't cover all the spectrum of what you'll want to test in a product.

Let's take your (excellent) libs and see:

- OUnit: unit tests

- QCheck: unit tests

- iTeML: unit tests

Where is integration and functional testing ? Unit Testing only test a very strict subset of the "does this work as intended" question. I recommend you to see how some projects do their testing. For example any classic Rails project. You could be surprised.

Some open questions I struggle myself to answer correctly:

- Mocking modules without having a build mess with oasis

- Managing the model in a sane way

- Integration testing is an horror

And many more that I can't recall now.

I don't know if it brings anything new on the table. Also, I am not convinced that Ocaml is state-of-the-art in term of development productivity, relase-management, debugging, etc. Anything any non-trivial project could want. Language features is not the only thing we need.

Yes, the OCaml tooling has really improved recently, and the OCaml workflow has been more and more smoother. Still. I wont recommend it for a business.

So, if the original author read this, could you answer these questions about how do you ship products with Ocaml:

- How do you do Quality Assurance ? (anything from unit-testing, integration testing, functional testing, etc. I guess you have to do it a lot to check that Gmail didn't break its integration). Testing in isolation has its share of challenges in Ocaml.

- How do you manage your builds and releases ? Private Opam repositories ? Directly shipped to Google ? Do you have beta/staging channels ?

- And last but not least, what have been the pain points so far and have you been able to fix them or do you just work with it ? (it happens with any tech stack, but it's good to know what the trade-off are)

I am very curious how this could work at "entreprise-scale" and I would be glad to have some real world examples of ocaml in production.

As a user, I am always a bit afraid that DuckDuckGo might be gone one day.

How do you keep the DuckDuckGo afloat ?

This is relevant to the discussion:

- http://udidahan.com/2007/12/29/wcf-everywhere-not-on-my-watc... (MS SOA technology)

- http://www.oracle.com/technetwork/issue-archive/2015/15-mar/...

- Also this: http://stackoverflow.com/questions/25501098/difference-betwe...

- http://service-architecture.blogspot.co.at/2014/03/microserv...

And here again we will see the raise of the mighty, the glorious ENTREPRISE SERVICE BUS.

https://en.wikipedia.org/wiki/Enterprise_service_bus

Were are my mainframes ? I think I'll need them soon.

Thanks for your reply. I now think I don't understand the logistic involved and will look further.

> I think that the US either has a national power grid, or has one for the West and East halves of the country

It would makes sense.

> Obviously, throwing power across the whole damn continent is far less efficient than just throwing it across a state.

For now. With the future high-temperature supra-conductive cabling we will be able to do wonders of efficiency on large distance.

Well, I have to say I don't know the US infrastructure enough to have a bold opinion, but I know heavy infrastructure like these often have a sound design respectively to their constraints (which can be absurd).

The European power grid is very tight and well-meshed, this is why we can let our nuclear power plant and sell electricity to Switzerland, Germany or Netherlands or buy it.

I guess it's not as well interconnected in the US, so that states can't easily lend power which disable the use of nuclear power plant for many states ?

> You seem to suggest that the fact that Fukushima was not adequately prepared for this tsunami was human failure, presumably because they should have expected such a tsunami to occur.

For your information, in France where we use nuclear energy a lot, we look for the most catastrophic events of the last 100 years to see how we protect our infrastructure.

The Japanese looked for the last 50, but there were a tsunami of similar height 85 years ago.

Also the local authority of nuclear security has made a few reports were they recommended to increase the height of the seawalls. Several times. Never followed.

And last but not least, the accident could have been prevented, but has been badly handled. With Japanese hiding information, not cooperating with trained international nuclear-firefighters, and minimizing the scale of the incident until the last minute. This is the biggest mistake of all, compromising lives, resources, ocean and earth...

How is it not a human failure ?

I suggest you to learn a bit about power grid engineering. Basically, the fact that we can't store electricity means that when you power on your toaster, somewhere a power plant has to increase its power to compensate.

But the nuclear power plant takes up to 2 days to startup. It's not sustainable for the daily life where consumption change every hour.

That's why there is the need for more agile power plant, where fuel, gas, and coal are suitable. Gas being the most agile but the less efficient, fuel and coal being used as the middle between gas and nuclear, depending of the price of each resource.

This is an engineering constraint before anything else.

exstudent2 made some really good points and you just answer it like an invocation in the church.

Seriously, we're not in the church here. It seems like a sensible matter to you and you seem angry, which will change nothing. So take a deep breath and go out to change your mind. There's nothing to win in this conversation and we will all be at the same place tomorrow. Take a break.