Which droplet would be best for between one to three people?
From what I gather, the ISP has to record the sites you visit—but not the specific pages. Does VPN stop my ISP from seeing the loaded sites? Or do I need Tor for that? I’m not too concerned about complete privacy, I just don’t want every website I just don’t want my browsing history to be leaked.
If you route traffic and DNS to a DO droplet outside the UK, all the ISP sees is a connection to that droplet and how much data was sent, not anything about what it was that was sent.
It neatly circumvents this bullshit, some suspect doing so will put you on a list for a closer look but if your traffic is innocuous who cares, I'm more worried about my useless ISP leaking/losing such data than I am about state intelligence.
Just the existence of these databases held by ISP's built under lowest cost bids will make them a massive target.
Possibly but I'd quite like to exit in another country sinces another layer of bureaucracy for them to deal with and not all countries have equal policies in terms of privacy.
Until the UK adopts rules regarding SIM card registration which are effective in some other European countries (I know of Germany and Poland): every pre-paid card must be associated with a specific person and vendors won't issue/activate you one until you present them with your ID card.
How is your opsec - i.e. do you vary your purchasing pattern, using random numbers to pick intervals between purchases and a variety of vendors?
I only ask, because routing everything over a VPN provides the illusion of privacy while flipping contracts every month provides some element of real privacy. It is easy enough to check on the activity of people pretending to hide their activity (assuming GCHQ has access to the same access that the NSA do), but real resources have to be spent tracking down people who actually hide their activity.
I have no idea how they allocate their budget for tracking potential threats, but somebody flipping prepaid sims would warrant a closer look if I was analysing the logs.
Indeed, that's a good point and I'm aware of that. They can absolutely track me given enough effort; they probably do it anyway since I'm a developer, I just try to make it a bit costlier for them I guess. For now, I don't bother much rotating vendors but it should be something I do indeed!
I wish they would stop making changes just for the shake of change. E.g. Up until 0.17 most code examples where using the prime ' character.
With 0.18, Evan decided that using prime is bad taste, so he decided to break any code that uses it.
Sure, it is not a big change, but it means they are not respecting user's time and it is a sign of things to come.
Sorry for the rant.
Edit: I hope my reply doesn't get misunderstood. I love Elm and use it in all my side projects. I think it made wonders for introducing new people to the ML world.
Edit2: Sorry, didn't meant to make so much fuss about it. It is indeed a small thing.
I agree... I wish we still had the prime character. But since Elm isn't at 1.x status yet, that earns me an "irritated smirk" rather than a table-flip. :)
Yes, I am not saying it is a big thing. It's a small thing in itself, but breaking backwards compatibility for no good reason is huge red flag for the future.
> breaking backwards compatibility for no good reason
I'd say reducing weird syntax is a perfectly good reason. How is doing this while offering an easy migration solution in an early stage language a "huge red flag"?
A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p...)
There's a very good example in C++ of how this causes problems, where vector::clear and vector::empty are much too easy to confuse (which one of them deletes all elements, and which one of them checks if a vector is empty?). Replacing them with clear! and empty? (or is it clear? and empty!) would be a huge improvement. Whenever a language moves away from arbitrary legacy restrictions, that's a good thing.
The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
I think that's a coding style decision, and shouldn't be part of language specification. I certainly don't feel about primes the way you do: having a function f and a function f' usually means they are sort of similar with some specific difference between them, definitely not "couldn't think of a better name". E.g., in haskell a prime often denotes a strict function, it's a better convention than having f and f_strict. Plus, how are you going to decide which unicode symbols should not be allowed? It can get a little random.
It's definitely a matter of taste, but I feel like settling for "similar except different somehow" is the same thing as "couldn't think of a better name". I would much prefer f-strict because then I don't need to be familiar with the punctuation conventions of the codebase to know how it's different from f, it's right there in English.
Edit: Plus, then you don't have to wonder if that particular function follows that naming convention; prime meaning strict isn't nearly as universally followed as ? or ! in Scheme, for instance.
I keep hearing this excuse, and to be honest I don't like it. On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse.
> I'd say reducing weird syntax is a perfectly good reason
I disagree with you on this, prohibiting the users from using the prime character has nothing to do with the language's syntax.
> On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse.
If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language.
Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's acknowledging reality. And an upside to that reality is that making these types of changes won't upset nearly as many people as it would if it were a more mature language.
> I disagree with you on this, for me it is very worrying.
> it would sound like there was some critical change to the core functionality of the language
No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so).
> 1. It confuses newbies.
Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.
Is a language that allows Unicode characters for variable names confusing for newbies?
> 2. It's an easy character to miss.
Again, it is in my code.
> 3. It's easy to migrate away from it.
That's not an argument for removing something.
Again, my point is that is has to do with personal taste, yet Evan decided to force it to anybody who uses the language.
He could have very easily enforce it to core packages, and nobody would complain. But forcing it on my code, is worrying.
> Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.
Until you take your personal style to Github, or coworkers...
Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.
If coworkers are unhappy with it, they can (and should) make guidelines for acceptable syntax. This is no different than using camel case in Java instead of snake case (or using the $ in identifiers, which is extremely rare). If it's a problem to use it in my code on Github, you can always use somebody else's code or fork mine to change it. Maybe we should use the compiler to force every line to have a comment so we don't have any undocumented code on Github too?
The creators see it appropriate to enforce their strange preferences with dubious reasoning. The enforcement (in standard Elm format) of a 4-sized tab[1] is just another example.
Like you said I'd not have the language community enforce what is acceptable down my throat, and that conflict of preferences within a team is best solved by making style guidelines instead of having the language community spoon-feed an authoritarian preference.
I completely agree with you. Evan isn't happy just controlling what packages you can publish that use the native api on package.elm-lang.org, or what you can do in the language since the removal of signals, he wants to control even minute things like whether you use a fucking prime in a function name in your own code. It's ridiculous.
People are excited by it, and managed to deal with prime-ageddon without any major headaches (it's like basic regex search and there's even an update tool, come on).
I actually think that's a terrible idea. `0.x`v versions are precisely the time to try and get this stuff in, before you end up locked into it forever.
I have been using Windows Insider builds since 2014. It is unique experience for me to see an operating system get developed week by week. Though it is a pain to upgrade (not update) OS every week but it is totally worth my excitement. If I have any resentment I go to feedback app to share my thoughts, and surprisingly I get response too once in while from MS team. MS is not same MS. VS Code is just fraction of what MS has become.
Although very fresh into the Haskell world myself, I tend to agree with the author that, when I know what I am doing, my Haskell code is usually written in less time and has less bugs.
Having said that, Time-to-Market is only partially influenced by my-code, the biggest part is the code that I don't have to write, i.e. third-party libraries.
In my Haskell adventures I am having trouble finding third-party libraries for even the most popular things, e.g. Cassandra. As far as I can tell there are two libraries, the `cassandra-cql` and the `cql-io`, the first hasn't been updated for a year now, and the second has only 3 stars, which makes me uneasy.
So, although I can see where the author is coming from, I don't think you can beat Java, Ruby, JS or Python in that sense. Unless of course your code/project doesn't have a lot of dependencies.
I've found Scala to be a really good compromise–it has most of the functional features of Haskell, a wide array of existing libraries, and access to Java libraries when you need them. Plus implicits/typeclasses make it easy to extend otherwise annoying Java libraries to make them easier to use.
Yes, when working in Haskell, expect to do some yak shaving.
It's some incredibly productive yak shaving, it's even fun, but it's still yak shaving.
But I'll point that Haskell has also many wonderful libraries, for stuff you won't see in other communities. The libraries that are available are of an unmatched quality. Odds are a library marked as experimental on Hackage is more reliable than a mature one on the Python Index.
Maybe. Windows had a single company behind it, and as I recall Bill had to issue a company-wide cease and desist order to get people to stop developing and focus on security for a while.
IoT may always be plagued by cheap hardware with buggy software from fly-by-night companies.
That is great advice. I have the same setup, except I use OVH instead of AWS because the cost is much lower, but still meets my needs (AWS, GCP, and Azure are all great services that I have used, no criticism intended).
> RethinkDB is something we were looking at for a large project
From the comments in HN it feels like this was always the case for RethinkDB; folks looking at it, admire it, thinking about using it in their next project but, for one reason or the another, never ending up using it. Which is really a pity.
I don't know about the others, but I am really curious to know why you ended up not picking RethinkDB for your project.
Good question, and one that is worthwhile asking as part of the post mortem process.
In our particular case it is because I (as lead technical person on projects) come from a 30+ year background in SQL. Moving to NoSQL is always a point of trepidation for me purely form a comfort and familiarity angle.
I must say though, in our investigation of NoSQL systems for a couple of projects ReThinkDB (and PouchDB for another mobile project) were the two that seemed to stand out, and seemed to make installation and testing easy, as well as remove a lot of the barriers to dipping a toe in the NoSQL ocean.
So, end of the day it wasn't really a technology issue, but rather came down to familiarity and habits.
NB: For the mobile project, we went with Back& (backand.com) which is essentially a NoSQL wrapper around a MySQL database that we have running behind it. It helped me to get my head around NoSQL while still letting our DBAs build out the data structures in pure SQL. Working well so far.
We were considering RethinkDB for a mobile project, but ended up using Postgres on the backend and Realm in the apps with a custom REST API in between. This worked out really well for us, apart from all the work on implementing our own REST based sync (this was before Realm launched their backend product, which might have made a lot of that work unnecessary).
The reason we ended up with Postgres over RethinkDB was that our data model was very relationship heavy in ways that were easier to represent in a relational database than with RethinkDB's document model.
+1. To expand on my own post above - one of the biggest things that scares me away from NoSQL solutions, apart from the fact that the schema is not 'set in stone' and can be changed anytime by anyone, is the relationship aspect.
Because we build business and ERP extensions most of the time, the requirement for multiple joins across sometimes up to 7 or 8 tables was what I found difficult to manage in NoSQL data stores. Foreign keys, LEFT OUTER JOIN, SELECT DISTINCT, GROUP BY etc. are all second nature to me in SQL, but totally Greek to me in NoSQL.
RethinkDB has joins and I found its grouping to be straightforward and super powerful. Selecting distinct values is as simple as putting .distinct() at the end of your ReQL. While it doesn't have foreign keys, any value can act as one as long as it holds a tables primary key (or other indexed fields), in which case you can do db.table('other_table').get(primary_key_val) (or getAll(foregin_key_val, {index: 'my_index'}) if not the PK, but otherwise indexed).
Granted, it won't validate that the keys exist, however (since its schemaless at the DB level), so nothing will prevent you from inserting a document with foreign keys that are invalid, but from a querying point of view, foreign keys are easy. Would be nice if you could set insert/update-checked constraints though.
You absolutely can set the schema into stone, even when using a nosql database. That 'stone' is in your application code instead of the database though. And even when you use SQL the schema can be changed anytime (by anyone, in practice in most small companies). ALTER TABLE ...
I see your point, and we do tighten security on our database so that only certain users can perform ALTER, DROP etc. No doubt that can be done on NoSQL as well.
I guess I was talking about 'inadvertent' database changes. It seems that things like a simple typo can end up creating new attributes in a table when you didn't want it to, e.g. lets say earlier in my code, I have:
mytable.thisthing = 1
Then later on, someone mis-types:
mytable.thatthing = 2
I now have TWO attributes in my table instead of having the original "thisthing" attribute changed to 2.
An app with an SQL backend will usually throw an 'object/column not found' error if it recognises an attribute/column that is not on the original spec, but a couple of the NoSQL systems I've dealt with will happily take that line of code and work away with it, making debugging down the track a bit of a nightmare.
I am sure you can harden your NoSQL service to prevent this sort of thing, but then it becomes a question of whether the extra effort involved is worth it as compared to sticking with SQL where you are more constrained, but have better control over inadvertent table changes.
I once worked on a system which consisted of about a half-dozen services and MongoDB. At some point we noticed that a large percentage of the documents in a certain collection had somehow had a Date field coerced to String, which caused a bunch of stuff to not work correctly.
A simple typo in your SQL DDL statement can cause 'inadvertent' database changes.
Just like you have your SQL schema defined in a central place, allow only a few select developers to make changes to it, and put any changes under extra scrutiny, you do the same when the schema is defined in your application code.
'.. but what if typos' is not a valid argument. Not in 2016. You can use code reviews, tools (compilers, static type checkers) and good software engineering practices to avoid problems due to typos.
I must admit that I haven't delved deeply into Graph databases at this stage. If I can see a compelling reason that NoSQL/Graph will be a better/easier solution than pure SQL on a project, I am willing to, as an old dog, learn new tricks. ;)
I elaborated on this quite a bit a month ago when it was posted[1], but the cliff's notes version is basically that Postgres + Solr turned out to perform better. It was also more familiar to us. I did actually prototype the project with it, and it affirmed a lot of my warm feelings, but performance was the deal breaker.
I'm really happy to see forward motion on this project though. It's the kind of thing I'd love to be involved in, if I were a completely different person.
After my first project with it, almost two years ago, I've used it in every applicable project since. It's exactly what I've been looking for in a database. Relational Documents, an easy to use query language, with realtime feeds. The fact that it didn't explode on the scene, is depressing. Because it takes all of the strengths from other document/nosql databases, and none of the weaknesses.
We are still using in production and for new projects. It's a very strong product with good engineering, documentation and is open source and have faith it will continue to be a viable option.
https://www.digitalocean.com/community/tutorials/how-to-setu...