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.
I must say you really do make it sound simple, and I generally like it. I think the part where I struggle most are the details though.
> document what PII you store
that part seems doable, the hardest part here are probably figuring out what PII is, and then take care of numerous services logging IP addresses. That's PII, isnt it? What about IPs of phone calls over IP? Or phone numbers stored in phones of numerous employees? Do companies delete those, or is it not necessary?
> who has access to it
I personally try to self-host as much as possible with as little third-parties involved as possible. But I think here are edge cases too, a lot of people might not think about, such as time tracking tools, calendaring, accounting software etc. What happens if employees just use online tools the employer doesn't know about? I am sure it's defined, but it's not entirely clear to me
> what you do with it
that's probably the easiest part, if you do something with it you probably know it
> Also have an internal procedure to scramble someone's PII on request.
I think that sounds good. It's just not entirely clear to me what that procedure should look like? How deep do we go with that? I could be nitpicking and say that physically information can not be destroyed. What if a SQL Server uses MVCC and doesn't delete data but just marks it as such? What about event sourcing architectures with kafka that rely on keeping the data? Or how about backups? Probably no deletion needed, but how to handle cases where backups are restored and previously deleted data reappears? I just think a clear set of rules would be great here, and a lot of people like to oversimplify things (or me, overcomplicating things here, probably)
The answer to most of these is the same: companies have to show that they are making a reasonable, good faith attempt to comply. If they can show that they have policies, that they have processes to implement the policies, and that their users have read the policies, understand the processes, and are aware of their own responsibilities then there's a strong likelihood that they will not run afoul of the directive.
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.
Misplaced sexualization very often is sexism. Sexism is more than singling out a particular person for their gender; it is also presenting an environment that is unwelcoming to those of a particular gender.
"Booth babes" used to be a staple at every conference. Over the last 10 years, they've become sharply disfavored, because staffing your trade show booth with scantily-clad women with no connection to your company is a fucking creepy thing to do.
People still do it, but by this time 5 years from now, everyone who does will be a pariah, trading on shock value. Those people/companies will always exist. Their existence isn't evidence that what they're doing is OK.
Oh, I wholeheartedly agree that they have "creepy" elements.
That said, this sub-thread is more nuanced. This article wasn't written because of "booth babes" offending someone at a conference that Microsoft helped sponsor.
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
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.
I'm always very amused when people say OCaml can't work at "enterprise scale" (let me snort a bit on that one, considering the scale of some open source projects) given the amount of evidences of the contrary[1]
To answer one of your question. Yes, we have testing frameworks, both for unit[2] (inline[3]) testing and property testing[4]. As for the rest, it's not OCaml specific at all. :)
> 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
Not sure about the other issues, but I believe this one is easily solved:
> Mocking modules without having a build mess with oasis
OCaml has parametrized modules (aka "functors"), which provide a very clean solution, compared to mocking whole modules anyway.
As a side note, I usually see mocking being used to test badly structured code. Refactoring that is usually a benefit for testing as well as a benefit for the code itself.
I'll tell you how we do these things in the libguestfs/virt-tools project [1]. The project is written in a mix of C, Perl and OCaml. Mainly C is used for the low-level/library bits, and OCaml is used for the higher-level tools.
- QA: We have some unit tests, but mainly we use a huge test suite that does end to end testing of tools. It uses automake's test framework, so it works across all the languages in the project.
- Builds and releases: We use autotools and tarballs. It's automated using a thing called 'goaljobs' which is like a generalized make.
- The pain points for us all derive from autotools itself, which is both crap and better than all the other build systems[2]. It is at least well understood.
I'd also say the killer advantages of OCaml for me are: Easy calling into C, and compiles to a native binary.
[2] I use the term "build system" in a rather narrow sense of something that (a) runs on Linux (b) lets the end user download a tarball and (c) builds using ./configure && make
I'm not sure why these things require state-of-the-art technology.
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?
It's been years since I used OCaml and I don't know anything about OPAM so I'm also interested in the answers.
Did you try to use OCaml and run into a bunch of difficult problems?
> 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.
Just as an aside, white box testing (#2) shouldn't be used for testing contracts between your inner interfaces, but rather, your consumption of some external interface that is hard to set up.
As an example, I want to make sure that when I hit a REST API endpoint, I do all my logic and get a proper return value (black box testing), maybe that the state of some bit that I've already set up is correctly changed (say, the database, by then checking it as part of the test to ensure the thing I said should be written was written), but that I also send a server sent event (SSE) to connected clients indicating the change. I don't want to actually have to have opened up clients that conform to the SSE specification as part of my integ tests (because that's a pain), so instead, I'll just assert that the library call to send that event does indeed get called with the right thing. From there, I can test once, that the library call does indeed lead to an SSE being sent to the browser (and can even write a full environment integ test with Selenium or something), and from then on, my single system tests just assert that call is made when it's supposed to. I'm effectively integration testing without implementing/mocking a connected user to test SSEs.
Similar things can be useful when putting items onto external queues, making calls to foreign interfaces, etc. You should never make assertions about the path through your code a call takes in white box testing (because refactoring can change those, and you have increased your test burden for little reason), you should care about side effects you can't easily otherwise test.
Thanks for the detailed response. I've used mocking frameworks in Java and while they can be pretty helpful it seems like the basic functionality is pretty easy to get at, for example heavy modules like database layers could be module parameters, or functional parameters, or however you want to structure it. Surely language features and cutting-edge test frameworks can make all this stuff easier, but to me it seems like it can all be done easily with the normal ways of doing abstraction (and OCaml is pretty good at abstraction).
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.
"Functor" might just be the most overloaded term in computer programming... Just of the top of my head it has totally different meanings in Ocaml, Haskell and C++.
They're not totally different between OCaml and Haskell. They're based on the same concept from Category Theory: a mapping of objects and morphisms from one category to another. It's just that Haskell functors are at the type level and OCaml's functors are at the module level.
Apparently F# has support for neither style of functor--it doesn't have parametric modules and it also doesn't have typeclasses. So in F# `map` is defined independently for each type:
Set.map : ('a -> 'b) -> 'a Set -> 'b Set
Seq.map : ('a -> 'b) -> 'a seq -> 'b seq
List.map : ('a -> 'b) -> 'a list -> 'b list
Array.map : ('a -> 'b) -> 'a [] -> 'b []
The IDE situation is now excellent (thanks to merlin[1]) and OPAM, the OCaml Package Manager, is the best package manager I have ever used.
The remaining pain point, as far as tooling goes, is the debugging situation, but steady progress has been made and it should receive very large improvements in the next OCaml version or so.
Well, I'm not sure I would go as far as "excellent". There is no "OCAML IDE", there is vim/emacs + tools. You can hack an IDE-like workflow by way of inotify, but if you want the "works-out-the-box" experience, that's not going to happen. As you mention, debugging is lacking, and more generally Merlin can't do much in the way of refactoring.
If you're fine with, eg, hacking Python in VIM, you'll be pleasantly surprised by the OCAML situation. If you live in an integrated IDE, there will be some adaptation.
Kind of. It's a bit awkward to get it running on Windows, but somehow (by accident) I managed to do a fully functioning installation on Cygwin. That said, many of the packages have still not been ported to Windows, so my recommendation is to set up a headless VM of some GNU/Linux distro and SSH into it.
Here is how I handle this at my company. LibreS3 is a product written in pure OCaml [1], using as a backend a cluster running Skylable SX (written in C)[2]:
- QA: unit tests written using oUnit, and integration tests by using linked Docker containers.
- builds/releases: opam + packages written for Debian and Fedora based distributions. The packages provided on our website are built inside Docker just like all the other packages. Internal beta packages are uploaded to a separate volume/bucket and served via LibreS3 itself.
- Pain points: building a package compliant with packaging policy is more complicated because I usually need newer versions, or OCaml libraries that are not yet packaged.
I planned to use opam to generate templates for LibreS3+dependencies but was waiting for the C backend to get packaged upstream first.
My slides from last year list a few more problems that I encountered during development but they aren't an issue currently [4].
The main advantages of OCaml for me are:
- the availability of high-level libraries that makes implementing HTTP APIs simpler (Ocsigen, Cryptokit, atdgen, etc.)
- event-driven/non-blocking architecture to support large number of concurrent users (Lwt)
- native binaries and static type system
- not having to look for certain bugs in my code like uninitialized variables, NULL dereferences, memory leaks or memory corruption bugs; which (used to) take up a significant amount of time when developing applications in C (although tooling on C side have improved with valgrind, clang -fsanitize= and Coverity).
That doesn't mean that code written in OCaml or the libraries that I use doesn't have bugs, I track them down
and provide patches just as I would for a C library.
Although perhaps writing code in OCaml has made me somewhat overconfident in my code, and I find bugs in other people's code more easier than in mine even if I'm not looking for them.
DuckDuckGo is actually profitable! It is a myth you need to track people to make money in Web search. Most of the money is still made without tracking people by showing you ads based on your keyword, i.e. type in car and get a car ad. These ads are lucrative because people have buying intent. All that tracking is for the rest of the Internet without this search intent, and that's why you're tracked across the Internet with those same ads.
I think it's great what you're doing (DDG is my default search engine). And I'm glad you're profitable so you can stay alive.
But I'd like to think that if you could find a way other than ads, you'd take it in a heartbeat, even if you made less profit, but as long as you could be self-sustaining. Is that true?
I have a very strong opinion about advertising and its effects on the web. I would love to hear your feedback on them:
I'm trying to spin up a movement to shift the web away from its reliance on ads. Let me know if you can be an advisor or resource for that. One day I might thank you in the way you thank all those other founders you listed above. :)
Yup, that's very true but the numbers just don't add up well on search in terms of subscription or donation. We have tried to do much less advertising, making it up on affiliate revenue, but we can't do that much because of our privacy policy. We can only use programs that can be anonymous, which means the companies run them themselves through URL parameters, and that's really just Amazon and eBay.
If you don't mind sharing, how much do you get through those affiliate programs compared to advertising?
Also, would you consider providing some kind of paid model in addition to ads? I use DDG dozens of times per day as my primary search engine; I would happily pay for it. I realize that model doesn't scale to the entire world, as only a fraction of people will pay, but do you have some way for people who like what you're doing to pay you a modest amount, with as little friction as Patreon and similar?
We haven't disclosed it, but advertising is the bulk.
The problem with paid is three-fold. We're a for-profit company so don't want to come off as taking donations like a non-profit. Second, we don't want to collect personal information. So we could do something like bitcoin but that isn't exactly low-friction :). Third, it is promoting that it exists. We have a hard problem getting the word out about anything not on the SERP and we wouldn't want to put it there.
Regarding personal information, I have no problem providing payment information, as long as that isn't tied to accounts/searches/etc. (A separate service, similar to Patreon, seems ideal.) But I do realize that the number of people willing to pay you may not justify the work needed to set something up.
I do understand your concern about not wanting to appear to take donations, though. I just wish I had some way to pay you for your service that doesn't involve viewing or clicking on ads.
We really suggest people who want to help to just help spreading DuckDuckGo, which is honestly our biggest problem (not money): https://duckduckgo.com/spread
I think that the fact that DDG has a no tracking policy allows users to turn their ad blocking off, this might contribute something towards profitability...
As an advertiser, I would love to advertise on DDG, but to do so, I have to use Bing which means 99% of my ad spend does NOT go to DDG. I don't care about tracking - just want to reach a great audience that is using DDG. Will it ever happen (DDG native ads)?
Give it a try !