I respect them too. Here in the UK I always try to say good morning and thanks to our bin collectors.
Do you know how many hours do they do? Is it the fact that when their route is complete they are finished for the day? Because then there is a pretty good incentive to work hard and fast.
I'm trying to wrap my head around how this, and tipping, works. Here (suburb of Boston), curbside trash collection is like a 10-second affair. Do you like wait outside on a lawn chair for hours and then run up to them waving your arms and shouting over the noise of the compactor truck?
I highly doubt that they're salaried, so the incentive would actually be to take longer to make more money. A more likely incentive for them to work fast is that they'll be fired if they don't.
We (stannp.com) created an app for the shopify marketplace some time ago which helped shops send letters and postcards to their customers. The app would sync recipients with our platform or trigger mail to be posted. The shopify rep said we had to implement their billing API on across our whole platform so they get a 30% (i'm sure it was 30% back then) cut on all transactions. It drove me crazy because I saw mailchip in the marketplace and I'm pretty sure they didn't implement the shopify billing API and give 30% for their subscriptions.
The official mailchimp app was also removed from the Shopify app store for not complying with the terms. Shopify doesn't care who you are, everyone is on the same terms now.
I used to use Netbeans for PHP dev and loved it but development of the IDE seemed to slow down and the transition to the Apache foundation took too long. I have since gotten very familiar to using VS Code with the PHP intelliSense addon. VS Code is very fast and light on resources and has an addon for almost everything.
It's betting that Google are better package maintainers than Debian/CentOS/Ubuntu, especially when it comes to maintaining container images. From a purely technical, and financial, point of view, it's likely true.
Of course, they could have bolstered the distro teams. And the fact that the repositories are within GCR, not Docker, is just convenience.
It brings you closer into Googles warm, technototalitarian embrace, is what I mean.
They've been at it (looks like) since ~2014, and their goals and motivations seem 100% in line with google, but at the package/distro level, not the container-base-image level (highly related): https://tests.reproducible-builds.org/debian/unstable/amd64/...
Exactly! This work builds on top of the Debian team's work on reproducible package builds, providing a way to combine all of these packages into a reproducible container image.
This is difficult with Docker directly today because timestamps appear all over the place. We designed and built a custom set of bazel rules to make this possible.
> goals and motivations seem 100% in line with google,
It's been a long time since I've believed in their idealism, yes, but I still think accusing Debian of being in the advertising and surveillance business is a bit harsh.
`This covers the Period January 1, 2017 – December 31, 2017`
`Gross Income -------- 635,311.59`
...and in that way, yes: google can afford more package maintainers, more scrutiny, but if they are "better package maintainers" it's at those margins and due to economics rather than ability or desire.
> My intent was to challenge your statement that google are better package maintainers than Debian, specifically w.r.t. reproducibility of builds.
Ah, I believe there's a misunderstanding coming from misreading of my statement: what I wrote is that the _reason to upgrade_ would be the _belief_ that they are better, and that if you restrict yourself to _certain measures_, they probably can, by throwing more money at the problem. I hoped that he latter part of my comment probably makes it rather clear that Google wouldn't actually be better as far as I'm concerned. Even from purely technical perspective, I'm fairly sure Debian is willing to support many architectures Google will ignore.
I do this too. Particularly when I'm reading something online or thinking. I was smoothing my sideburns whilst reading this post, looking for "that special hair". I favour my sideburns and beard.
Heh, I was just doing it with my eyebrow. Noticed a harder, thicker hair among the softer hairs. Pulled out five other hairs before getting it. Probably have a hole in my brow now.
I have looked at react.js a couple times after reading more and more buzz about how fantastic it is. However I'm instantly turned off of switching to it when I read that HTML (which isn't HTML and is actually something called JSX) goes in your js files.
With angular I can keep all my HTML in my HTML files. Is this normal or am I completely missing something?
Ask yourself why that bothers you and boil down your objections to a practical point. You can then evaluate whether there is a real cost and whether it's outweighed by other things.
A lot of these issues turn out to be things we learnt were bad ages ago and have forgotten why. The original context you learnt in might be sufficiently different or other factors might mitigate the underlying issue.
In the case of JSX - we were all told that to keep css, js and html separate - that inlines js and styles are bad. These things are all partially true but in a react.js project your components are usually tiny and there is always an inescapable dependence between js and html. It is therefore very different from when we used to see long html documents littered with onclick.
Except that there are use cases where you want to use boilerplate HTML in more than one component (i.e. bootstrap). Also, I've never quite understood the argument that everything that goes into defining a component should live in one file. By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries - heck - why not put the tests in the component while your at it.
The real reason we keep "technologies" separate is so that we understand what realm we're working at any given moment. Furthermore, we can distribute responsibilities across multiple team members focused on different disciplines. Facebook has the kind of clout internally to force their designers to use JSX and inline styles, but many organizations do not have that kind of alignment.
> Except that there are use cases where you want to use boilerplate HTML in more than one component
In this case, you can split out that boilerplate into a separate, smaller component and reuse it inside as many other components as you need.
> By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries.
I respectfully disagree with your inference here - such functions can be abstracted and used by many components - in most cases there's no value in baking them directly into a component.
The exception to this is if the function is not abstract at all, makes no sense outside the context of the component, and therefore can't be reused. Then, it probably makes more sense to put it inside the component, rather than breaking it out into a separate file.
This is true of most if not all of the markup and styles used inside a component, which is why React encourages JSX and inline styles to be put directly inside the component as it's the only place they make sense, and the only place they'll be used. The markup, styles and component behaviour are intrinsically coupled, there is a lot of 1:1 referencing, and separating them out into separate files means you'll just be flicking between three files when working on a component, instead of one. Where there is 1:n referencing, well, that's when you should break your component into smaller, reusable pieces.
I think it's all fine and dandy, and I like the idea of isolated components, but I'm not sold on shoving everything into one file. It just smacks of preference.
So split it up. Most React projects make use of Webpack or Browserify, or use ES6 modules via Babel. There are emerging patterns for keeping concerns in separate places but still having one component you can drop in declaratively.
Then just put all the files for a component into a single folder, which translates 1 to 1. Again, this is all just a matter of preference, and with pre-compilers you could glob all your js/css/html into one file using any framework if you really wanted to. Seems silly to me, but to each their own.
It bothers me because my super intelligent HTML editor becomes useless if I choose to use React.
The reason like Knockout.js because all the magic happens in a standard data-bind attribute, no funky syntax or paradigm shifts required. A purely functional solution like React seems like it's good for making games. Beyond that, for most sites, I think it would be more work to use React for little to no gain.
Knockout is a decent framework, I am using it on a large application currently. It has made some things that would be very hard much easier.
However it has a few issues.
1. Wrapping everything in observables is a bit annoying. Subtle issues can arise here in there especially if using the mapping plugin (which you kind of have to, it makes the process bearable).
2. If you start to have a lot of bindings on a page (a few hundred) performance degrades rapidly and there is a ton of DOM thrashing. Part of the problem is that a binding places an event handler directly on the DOM element. But there is also the initial load "flicker"/DOM thrash which for a significant page can take a second or two.
3. There are lots of workarounds such as rate limited observables, etc... But these are applied individually and become very tedious. They do not solve the entire problem either.
React solves all 3 of these so I can see significant benefits there. I have not switched myself but am experimenting. I do think Flux, Stores, etc.. are very overkill and actually poor architecture. But thankfully there are many alternatives cropping up which are much better.
There are definitely some issues. Regarding the mapping plugin, I managed to build a large custom CRM and accounts payable system without using it, but I did have to build out some custom routines in order to standardize my workflow...
React.js seems like it could be a good core for something like those alternative frameworks that you mentioned popping up. Aurelia looks interesting to me, but I don't think it uses React by default.
Yes, this appears to be the normal reaction to JSX (it took me 3 months to actually try React just because of the idea of it - more fool me).
My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern.
One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file.
JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).
Once I started using React in practice though, it turned out to be pretty nice. It significantly reduces cognitive overhead when thinking about frontend elements. And if you're worried about your javascript file starting to look more like an HTML file, composition of JSX components helps break things up.
Even if I can't convince you that it's actually pretty nice, you can write React without using any JSX. Just use a live compiler http://facebook.github.io/react/jsx-compiler.html to translate any documentation into the vanilla JS equivalent.
There are plenty of examples in other frameworks, e.g. sometimes view helpers in Rails output HTML. In certain situations it helps you write much cleaner code and it's easier to make more complex view components. Rails form helpers output HTML.
Since it is code that just translates to javascript, it's nice because you can have onClick handlers and such right inline, without having the downsides of inline javascript. You build reusable components that are self contained with their content and their logic. So you know when you use a component, the logic comes with it. You don't miss out on important bindings.
Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.
The concept behind directives like ng-click is actually pretty simple underneath.
The Angular parser will go through the elements in the DOM and look for attributes it knows about like ng-click. When it finds ng-click, it will run the expression "myEvent()" on the controller's $scope.
Yes, i think you miss something important here. It's a tradeoff. You should make your choice based on pros and cons, it's more objective than subjective when you hate something and you don't use it. It's harmful and useless thought:)
Hercules was a video card, not a terminal. The color for monochrome is defined by the monitor, of course. Green phosphor CRTs were quite common in the IBM PC world (starting with IBM's original 5151 monitor I think), but for terminals actually used on Unix machines other colors were more typical. The VT-100 series were blue, I believe; and later DEC terminals went with amber. White was reasonably common. I don't think I ever used a real terminal on a Unix box with a green phosphor.
My mistake, i was remembering old pc 8086 with hercules card and green monitor. Also that look resembled the ibm3151 green terminals, but i liked more the yellowish ones.
