Great question. Let me preface this by saying I HATE talking about RSpec best practices. It's irrelevant to shipping software and tends to churn up a lot of long, useless discussion. However, I think it's useful to consider best practices when there is a demonstrable functional (not stylistic) difference between two approaches that can affect maintainability, flexibility, and speed.
One style I see quite a lot looks a bit like this:
| version: '2' | |
| services: | |
| api: | |
| volumes: | |
| - "nfsmount:${CONTAINER_DIR}" | |
| volumes: | |
| nfsmount: | |
| driver: local | |
| driver_opts: |
There is so many information about css in the internet but most of the stuff, is totally non-sense and is just misleading people into copy & pasting bullshit where they don't understand why it is are working.
This is one of the biggest issues of frontend design! Thats why so many designs/websites fail. Especially cross-browser.
It is just a little you need to know, to truely understand how css is working. I hope these informations from other wonderful authors help you to improve yourself and make frontend and css work less painfull
| #include <curl/curl.h> | |
| #include <string> | |
| size_t writeFunction(void *ptr, size_t size, size_t nmemb, std::string* data) { | |
| data->append((char*) ptr, size * nmemb); | |
| return size * nmemb; | |
| } | |
| int main(int argc, char** argv) { | |
| auto curl = curl_easy_init(); |
Allow routing allocations:
curl -XPUT localhost:9200/_cluster/settings -d '{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}'
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| var Engine = require("famous/core/Engine"); | |
| var Surface = require("famous/core/Surface"); | |
| var Scrollview = require('famous/views/Scrollview'); | |
| mainContext = Engine.createContext(); | |
| scrollview = new Scrollview({direction:0}); | |
| var surfaces = []; |
| #The MIT License (MIT) | |
| # | |
| #Copyright (c) 2015 Andre Queiroz | |
| # | |
| #Permission is hereby granted, free of charge, to any person obtaining a copy | |
| #of this software and associated documentation files (the "Software"), to deal | |
| #in the Software without restriction, including without limitation the rights | |
| #to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
| #copies of the Software, and to permit persons to whom the Software is | |
| #furnished to do so, subject to the following conditions: |
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
