Él means he.
806 karma · joined January 3, 2014
Él means he.
Source: I have the same experience.
"noSQL" should be read as "not-only sql" and I think sql in this acronym should be interpreted as "relational databases". I think the relational model is convenient for a lot of purposes but at some point (maybe ~10 years ago) some companies where trying to use it for everything even when those things didn't actually fit in that model. So, "noSQL" for me actually means "alternatives" for different kinds of data time-series, graph, key-value, documents, etc. with redis, neo4j, graphite, mongodb, etc.
What I would like to see in the future is some ecosystem based on small pluggable modules that you can use to build the embedded store for a micro-services. Instead of using a full-feature database system (relational or not) you assemble your store like Legos with only the stuff you need. Something like this https://github.com/level/levelup/wiki/Modules
Then it is definitely interesting :)
I think AWS might be cheaper in this regard but less predictable, so it is a tradeoff.
Edit: I haven't looked yet into "Spot Fleets".
I might be completely wrong but thats what I always though, please correct me.
http://docs.aws.amazon.com/cli/latest/reference/ec2/get-cons...
I think most people launching instances manually or by other means never do this.
Edit: I'd love to contribute it but my golang skills are weak, few months ago I contributed something very small. I really love terraform.
I guess there are different kind of personalities, some people prefer working from an office others prefer working from an Starbucks. I have a coworker who prefers the library.
My ultimate "office perk" is no meetings over skype/hangout/zoom/gotomeeting.
Big chains are not exempt.
But you can still buy frozen burguers for instance.
This allow us to define the parameters of the token bucket on the service instead of the application like:
'requests':
per_second: 100
size: 200
Then in the app is like conformant = limitd.take('request', ip, 1)
I found the token bucket alg to be useful in a lot of scenarios not only for rate limiting but also for any kind of event debouncing. A common example: lets say you want to email a user everytime they trigger some condition on the system but you dont want to send the same mail more than once a day.Our project is opensource, we still working on it:
Regarding performance of node.js applications I often find myself looking at my cpu profiles and memory dumps in node-inspector because the most common problems are eventloop starvation, memory leaks or long GC pauses.
How do we maintain mental sanity? We define all our infrastructure on code (terraform) and we have found the right abstraction in the tool: modules. One module output is used as input on another module. Let's say you have a module to create and configure a bucket exporting the arn of the bucket, then another module to create the autoscaling-group along with its security groups, IAM Role and Policy. All changes are made through pull-requests and reviewed.
If you want to know who has access to a resource you read the dsl. I havent seen any tool to query aws api that way. It might be complex to build because policies can have all sort of wildcards.
I also remember we did a board for writing the program in the pic because it was too expensive in my country.
4 years ago I started to work more with js and then node.js until I stopped working on c#. Js has been for me a gateway to transition to other languages and get paid for that. I learned bash, python, a bit of ruby, go, etc.
If I see c# code today I don't understand what it does. Sure every version has a lot of new very useful stuff but it also introduces noise, "why he used out x instead of the new shiny out var x, he might not know about it, lets send PR".
Along the way I have learned to appreciate simpler languages that does not change that often. Where there are few or just one way to do something.
I think I read an interview to Mitchel Hashimoto (hashicorp) and he said he choose Go over all languages because it was boring.
A boring and simple language allows you to focus on the problem you are solving. A language that doesn't change for years allows people to catch up and master the tool. It also means that you can open a file written by someone else years ago and understand what it does.
IMHO js was in that sweet spot until ES6.
I guess this is just because there is no company doing it properly and maybe no market for it.
I am tall 1.90m (6'3"). I want to take classes further but I think I should find another plane.
Note: I used a Fiat 600 for like 6 months. I think the 152 is smaller inside.
For a proof of this, read haveibeenpwned.com. Troy blog is amazing.
If you are an startup, it might be better to invest your time in your idea and not poorly implementing authentication on your own. Yes, google might have issues but I am sure they have more engineers dedicated just to that thing, not only coding but also monitoring.
> let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one.
I hear you, I have been in both sides. When we started we used to use everything as a service because we didn't even understand how to manage some things like a database, as our OPs team grew we started to move things inside our infrastructure sometimes just to be able to restart them on failures. It is a trade-off and I guess it has a lot to do with the service you are hiring, SLAs, etc.
Google is sending an email every time you login in a different OS or browser even if you are on the same city.
There are a lot of things that can be done though. Facebook and Netflix [1] for instance are crawling the web for leaks and pastes, once they find one of their user's password they will force the user to change their password. Auth0 is a authentication-as-a-service and we offer this as a feature [2].
I have worked on this feature and several related features, my advice is don't ask for a password in your public website. If you think is easy, you are wrong, it is a lot of work to code it correctly but it is also a lot of work maintaining the system. Brute force protection, anomaly detection, detecting when your user password has been leak by a third party, etc. It is simpler to authenticate by using a third party like google, you just have to be careful about implementing oauth flows correctly.
DISCLAIMER: I work for Auth0.
1: http://www.dailymail.co.uk/sciencetech/article-3628950/Time-...
2: https://auth0.com/blog/announcing-password-breach-detection/
The interesting thing is that there is also an evil crawler that will automatically launch thousands of windows vms to mine bitcoins (that's all they do). Amazon told us that we have leaked our account id and secret but also they notice the other crawler has launched a lot of VMs and they did a refund to us. yes, we love amazon.
Lesson learned: you never put the account id and secret in your code, not only that you should not hardcode it, but there is no need to even read that from the environment etc.
Don't do something like this `new S3({accountKey: ..., accountSecret: ..}` instead you do `new S3()` and that's it. Every AWS SDKS is smart enough to find the keys in the environment following a series of steps:
- environment variables
- ~/.aws/credentials
- and when your code is run on ec2, lambda, etc. you should use IAM Roles.
So, in addition to not hardcoding an AWS secret, your code should not even pass the secret to the SDK.
Consider also enabling CloudTrail and have alerts on that.
There is also a way to not have ~/.aws/credentials in your machine and have another thing that requires MFA. I am not familiar how this work yet but we started to use it.
The other reason is slowness to open a single file from the CLI, it seems Atom doesnt reuse the already open shell like sublime does, there was a tracked issue for that one.
I still feel cheated by Intel, because working on that crap was like working on an airplane turbine. The noise and the heat was impossible to tolerate to the point that some companies started to sell solutions for this thing back then, some even using water. I ended up buying a huge blue dissipator.
Intel used me to test their new Hyperthreading technology, the processor was called Prescott, a.k.a "Pres-Hot".
I tweeted few weeks ago that I moved here and found another guy in IT few kms away. Also the first week I invited two neighbours to a bbq (asado!) and turns out one of the guys worked for HP. Not enough for a meetup yet but I am considering havig some beers with them.
My wife didn't want to move out few years ago, two weeks after living here she told me that she was very happy to live here and she suffer every time she had to go to the city.
My 11 daughter has done more friends here in two months than in her entire life living in the city and my son 4yo son is about to learn to ride a bike.
My advice will be at least to try it out, it will change your life for ever.