Here's a very short and snappy explanation for why so much of the UK's government IT infrastructure is so fantastically, awfully bad: it's an RFP from a Northern Irish government business development fund for a "Content Management System to manage all Invest NI websites and intranets." Here's how they express their priorities:
IV.2.1)Award criteria
The most economically advantageous tender in terms of1. Price. Weighting 95
2. Quality. Weighting 5
This is for a 523 000 GBP contract, by the way.
    
|
I am a committed Tabasco Sauce fiend. It is neither too hot, nor too mild, nor too vinegary -- I put it on pretty much everything. I'd use it for contact lens solution if I could. My life was radically transformed by my discovery of tiny, individual Tabasco sachets that aviation security X-rays don't identify as liquids, which means I can carry Tabasco with me at all times without worrying about getting stopped at airports for not having a stupid baggie with my liquids in it.
I found this video describing the production of Tabasco absolutely riveting. The fermentation process, the salted barrels, and let us not forget le petit baton rouge.
How Its Made - Hot Sauce (Thanks, Fipi Lele!) 
|
|
whatever story you are interested about in this post, one is that I've proposed a patch to V8 engine (please star it so it gets in faster) to accept a --expose-proto-setter flag at runtime able to expose the proper __proto__ setter so that my node JS pull request could start warning modules using __proto__ instead of Object.setPrototypeOf(target, proto).
What can I say ... open source is beautiful, you can potentially patch everything you want for anything you need ... even behind stubborn, politics, or decisions nobody agreed on :P
Now back to the original post ...
first thing: I write HTML manually in the textarea instead of Markdown, yeah!!!
Why? 'cause nobody on the internet moves fast ... really, no-bloody-body!
so ... back to manual tags writing instead of broken meaningless layout created via magic html editor ... yeeeeeeah!
I know this is getting boring and annoying, and I swear I wish I could say it's the last post but every day there's something more and this story is getting both entertaining and ridiculous!
I gonna tell you how I ended up blocked in Zepto.js repository, and how the rest of reasonable developers are acting instead.
This time, the experiment, is me reporting this story and nothing else. I give you links, I give you facts!
Quick note: they keep telling me I should let it go, but "I cannot sleep anymore" because of this so here my attempt to describe the whole story! Have a coffee, some new tab link to click and dig into, and please, please, keep reading ... also because you might realize ...
Isaac Z. Schlueter, the man behind node.js, twitted this
@littlecalculist So, why hasn't that been removed in favor of Object.setPrototypeOf? Got a link to discussions, or a shorthand version?
The conversation keeps going and has one conclusion
@izs one-line fix: delete Object.prototype.__proto__; // put this in a module called "raygun-neutralizer" :)
Ha ha ha .. so funny the future of JavaScript comes with a foot-raygun included, don't you think? ^_^
Breaking news, uh? The internal ObjectSetProto function simply wraps exactly what I've proposed in es-discuss as Object.setPrototypeOf(target, proto).
In V8 internals represented as return %SetPrototype(this, obj);
So here the first thing: the engine of miracles needs such power but we, stupid JavaScripters, how do we dare!
Not only this is the less consistent and the most ridiculous property ever introduced in Javascript, this is also intentionally poisoned as broken in Google engine.
These are a couple of quotes in my last attempt to make people reasonable in es-discuss, the first one is from Alex Russell, in this reply:
Assuming "this property" is __proto__, that ship sailed in V8 a long ago and there's zero chance of it ever being removed. It they want to remove it, they can simply fork V8 or ask for a build flag for it.
Not only this is alarming me, as V8 incapable of making changes if considered dangerous as security problems would be, but turned also out that Alex was wrong since today __proto__ is configurable so you can delete it..
.. and all you need to do, after forking, is to build putting a comment here.
set: desc.getSet(),// === ObjectSetProto ? ObjectPoisonProto
// : desc.getSet(),
That's it, after that you can have both __proto__ and a usable descriptor of it.
At this point, after a line change in V8 source code, all node.js could do to have a better environment is to do this during the sturtup:
(function(setPrototypeOf){
if (setPrototypeOf in Object) return;
var set = Object.getOwnPropertyDescriptor(
Object.prototype, '__proto__'
).set;
Object.defineProperty(
Object,
setPrototypeOf,
{
enumerable: false,
configurable: true,
value: function setPrototypeOf(target, proto) {
set.call(target, proto);
return target;
}
}
);
// TA-DAAAAAAA!!!
delete Object.prototype.__proto__;
// problem solved
}('setPrototypeOf'));
// example
var a = {},
b = Object.setPrototypeOf({}, a);
a.isPrototypeOf(b); // true!
Above scenario does not look like so hard to implement, isn't it Brendan?
However, another concern was about all npm modules will be broken without considering node has versioning so that no, not a single npm will be broken and updated modules could easily swap to this new API maintaining the environment nice, still fast, and clean!
Moreover, the Object.setPrototypeOf equivalent, called ObjectSetProto and wrapping %SetPrototype(this, proto) in V8, is used to set all __proto__ properties, how cool is that?!
InstallGetterSetter($Object.prototype, "__proto__",
ObjectGetProto, /* ARE YOU READY???? */ ObjectSetProto);
In few words, my proposal is naturally part of the language ... uh wait, this specific features has been commented as:
an added, _de novo_ API that no one wants, which is an ambient capability on Object, is bad and it won't happen
... it was here!
How would any developer want more power under her/his hands ... don't you dare thinking about it!
Brendan Eich excellently summarized with all links the story behind this property.
In few words, this property has been discussed and nobody wanted it.
They better preferred to quickly, dirty, spec it as configurable, at least, and as non present in Object.create(null) objects, so that finally some project could directly get rid of it and drop it viadelete Object.prototype.__proto__;
as mentioned before.
Moreover, this is another quote from Brendan the same es-discuss post:
Because @izs tweeted something you think Node is going to fork V8? Get real!
The change required to make that possible in V8 is a 10 seconds task, network push a part ... anyway ...
In Isaac slides you can read at page 26 that:
not developing a language removes a huge burden. Let TC-39 and V8 fight those battles for us!
So I didn't even bother him with this discussion ... I mean, he's doing the right thing: let other specialists solve problems for you so you can focus on something else .. right ?
The reality is that even if I send that patch to V8, they will not accept it, not even if Microsoft will agree as the right direction to promote a better standard!
The parody about this de-facto utopia is that all current IE browsers do not support __proto__.
IE is desperate to be part of the not finalized yet spec, and this is probably why the leaked version 11 shows __proto__ shenanigans in the wild .. and those specs are not final ...!
Since I've been fighting, blogging, and discussing this problem for months, and since many times they came back to me or others saying that:
It wasn't Node.js that drove that -- it was the "mobile (iOS WebKit first) web" that wanted __proto__ due to libraries such as Zepto.
So I've tried to reply at some point like:
I think zepto is using that to modify runtime NodeList results after querySelectorAll but in any case it was not me saying that __proto__ isn't used already...
The discussion goes on and on until I think one action is better than many words, right?
The good @awbjs, who writes ECMAScript Specifications, took kindly some of his time to reply to my post entitled Yet Another Reason To Drop __proto__.
This is his comment:
__proto__ wasn't TC39's mistake and everybody who participates on TC39 is aware of how terrible it is.
...
If you want to eliminate __proto__ you will have to eliminate its usage. Write a shim for Object.setPrototypeOf:
...
Then evangelize web developers like crazy to update all their existing deployed code to use this shim instead of directly using __proto__.
...
Good luck (seriously)
Challenge Accepted! ... so here the big drama ... that Allen "Good luck (seriously)" "benediction" transpiled in my mind as:
What the hack ... what does he mean with "goog luck (seriusly)", that JavaScript community is made by passive bigot developers that cannot change simple things?
Of course we are as good developers as those you can find in any other language ... let me demonstrate it describing the situation in apull requestcommit with all tests greens and zero side effects!
Sure that once described the problem in Zepto.js repository, and I swear never a Zepto.js developer I know ever showed up in es-discuss or my blog, I've simply committed a patch that was tests approved and changing two lines of code promoting Object.setPrototypeOf instead of __proto__.
Long story short:
Here the Thomas rant, accusing me of trolling, after (kinda obviously) him not being aware of anything I've been written 'till now:
It's not about not agreeing with you. It's the form of how you imply or directly state that we're, I quote, "passive bigots" and that somehow __proto__ is insecure and "may" be removed and other weasel words that imply that we don't know what we're doing and you're a white knight to rescue us from ourselves. No, thank you. Please troll someone else.
Now, whatever Thomas thought was good to demonstrate with his reaction, which is simply, in my opinion, "the ball here is mine, nobody plays if I'm pissed off" ... since he decided to block me from the whole repository, all I could do is to write an answer in the same gist that is describing the current madness behind that property.
Really Thomas ... what can I say, congrats!
So if IE will spec a document that's still a draft, and just to make for the broken web __proto__ can create, don't blame anyone if IE will implement that as broken as it is now almost spec'd!
Version 9 won't have it and neither 10, the current one in 2013!
If Zepto.js decides IE is not a target browser, this does not mean every library should decide the same!
Isn't one of our duty, as Web developers, to make the Web available to as many people as possible?
jQuery released today version 2 and IE9 and IE10 are supported, as easy as that .. or maybe that was the reason you were so nervous?
If Zepto wants to shoot in its foot saying __proto__ or nothing .. deal with that, you have less targets there and of course, you know that!
I mean, you better support IE9 and 10 in both Desktop and mobile for a while in any case, don't you?
So since this is the best moment to drop that mistake and go for a better, less obtrusive, pattern, why wouldn't you?
I am still blocked as if I've been trolling Zepto since ever but at least now Thomas rant is gone and there is a statement from Mislav Marohnić there I cannot comment but that makes sense for that library, except when it comes to talking about standards, since __proto__ is not even standard yet:
We generally don't pull contributions that don't improve anything. If, for instance, IE implemented the standard API but doesn't support __proto__, we would pull this. But we don't gain anything tangible with this change. We only believe in standards if they actually result in some benefit. We don't know what the "future of JS" is going to be, so we're making this neat little library that works in the present. When the future of JS arrives, I'm sure we'll adapt accordingly.
First of all, as I've said, is not just me ...
Secondly, __proto__ cannot be polyfilled while a modern Object.setPrototypeOf method could be much easier and consistently polyfilled across current browsers.
ES6 specifications aren't going out anny time soon so it's not too late to put a simple method out there able to make the future a bit brighter .. for node.js, for quickly updated browsers, for JavaScript, your favorite programming language.
You don't want too much power in a function? You shouldn't care since the language behind that function has it, so you are just thinking you should be limited, no matter how good or powerful or evil the function will be.
Thanks for reading until here, really appreciated!
Very gracious of them not to point out that Anne would totally have preferred Radiohead.Yesterday night Justin Bieber visited the Anne Frank House, together with his friends and guards. Fans were waiting outside to see a glimpse of him. He stayed more than an hour in the museum. In our guestbook he wrote: "Truly inspiring to be able to come here. Anne was a great girl. Hopefully she would have been a belieber." Tonight Bieber will give a concert in Arnhem in the Netherlands.
|
|
The first rule of building on top of another company’s platform: Make sure you play by the rules.
The latest case in point: Ribbon, a Twitter-based payments startup, launched a new product on Wednesday morning, and it looked pretty cool. The main draw was the ability to buy stuff from inside a tweet, simply by clicking on a button and entering your credit card info and shipping deets.
I’m not gonna give you the play-by-play here (as it’s super nerdy stuff). But long story short, Twitter shut off support to Ribbon’s new feature within a few hours after launch. The company flipped out, wrote a huffy blog post about the incident, and quickly reached out to media outlets about the upset.
Here’s the thing. Ribbon’s new payment platform rests on Twitter’s “cards” technology, Twitter’s much-hyped way of helping developers make their tweets richer. There are photo cards, text-based cards, video player cards, and other more recent additions like product and app cards, and developers still need Twitter’s approval to implement them.
According to a source familiar with how cards work, however, it looks like Ribbon wasn’t playing by the rules. Today, Twitter doesn’t support making payments with cards. But what Ribbon could have done was request approval for one type of card — say, a video player card — and then switch up what would actually be happening after launching the product. In other words: Request player card access, then hack together a payments workaround to put into the card after the fact.
Part of me wants to congratulate Ribbon for hacking together a solution. Good for you guys! Ingenuity is always cool to see on major platforms, especially when introducing shiny new products that Twitter hasn’t even introduced — or officially supported — yet. It’s the hacker way! Or something.
But another part of me wonders why Ribbon — or a developer like Ribbon — needed to jump the gun in the first place. For a long time now, Twitter has hinted at e-commerce options coming to its platform at some point in the future. Global revenue president Adam Bain has publicly remarked on the future of purchasing things through Twitter, how “buying directly from tweets will be huge” at some point.
In short, this is obviously a direction Twitter wants to go. So why hop the line and hack together a workaround? It attracts a flurry of negative, twitch-level press, and most likely gets your startup on Twitter’s bad side. Not sure if its worth it just to be the first product to market on a platform.
“Like any developer on Twitter, we had a hunch that this might happen,” Hany Rashwan, CEO of Ribbon, told me. “However, we’ve had extensive contact with Twitter about what we’re building and finding ways of working together. We’re still excited about the possibilities of what we can build and are looking forward to working with them in the future.” He maintained that the two companies are still in contact.
Twitter didn’t have a comment on the matter.
But it’s not only happening in the Twitterverse. Facebook developers also skirt the line of what’s acceptable and what’s prohibited to be built atop Facebook’s platform. And when the startups get shut down, they inevitably make a big stink about it in the press. Same with Apple’s App Store guideline violations, and Google’s Android Play store escapades.
Now, I’ll be fair to small-timers here, too. All of these companies — Facebook, Twitter, Apple, Google — have penned murky, hard to decipher policies for third-party developers, occasionally making it difficult to know when one is or isn’t breaking the rules. And especially in the cases of Facebook and Twitter, the rules have changed so much in the past few years, it’s difficult to keep up with what is and isn’t above board.
But from what I’m hearing this time around, Ribbon was trying to cut in line. And Twitter seems to not be having it.
My humble suggestion: Play by the rules next time, little startup. Just cross your fingers that those rules stay the same.
At Davos 2013, CEO Marissa Mayer unveiled her vision for Yahoo’s rebirth, affirming it wants to be:
a feed of information that is ordered, the Web is ordered for you and is also on your mobile phone.
It’s a laudable vision. With the decline of traditional gatekeepers of information, the original directory of the Information Superhighway could conceivably become again an “orderer” of the abundance of information we live in. Yahoo also has an abundance of mobiles apps, on iOS alone: Search, Flickr, Mail, Finance, News, IntoNow, Messenger, TimeTraveler, Axis, MarketDash, Sportacular, Fantasy Baseball, Basketball, Hockey, Cricket and Football, as well as feeds into Siri queries and built-in Weather and Stocks apps.
It would thus appear Yahoo both “has content” and “gets mobile.” Unfortunately, when dealing with information for the past 15 years, Yahoo has been confusing “ordered information” with “content aggregation” and “task completion.” While ordered information is presumably better than unordered information, simple aggregation — and that’s all Yahoo has, for the most part — is still quite low on the online food chain, both for Yahoo’s bottom line as well as utility to its users.
What then for a company like Yahoo — cyclically self-described as a search, media, technology, portal and advertising company — could go wrong in a rebirth process? Let’s take a page from Yahoo! Finance, a property that has long dominated its space against old (Microsoft, AOL) and relatively new (Morningstar, Google) competitors, for it neatly displays the degree of trouble Yahoo is in.
Is it “ordered”?
Scanning top-to-bottom a page of stock quote for AAPL, there are three disparately located Search departure points [1, 2, 3] all styled differently: [1] “Search Web” is the most emphasized one of the three. And yet it’s for generic search, even though I’m already at a highly specialized finance site.
[2] “Get Quotes” is finance-specific, but then [3], not a button but a text-link, is named “Finance Search” and yet, inexplicably, takes you to another page with a completely different UI and a generic searchbox with text-links to images, video, shopping, etc., not unlike the giant generic “Search Web” [1] just above it. Baffling for a company that still harbors search aspirations.
[4] Instead of a single banner ad, there are four small ad-buttons for competing trading tools right next to each other. I’m sure some people click on those, but what a waste of prime real estate for premium monetization.
[5] If you wanted to see the price of the stock you’re currently looking at in the context of Dow and Nasdaq as people would want to do, well, you’re out of luck. It’s to the left, on top the navigation column, above the ads.
[6] Why on earth is it necessary for Yahoo to display a Facebook Like button with running tally on an individual stock quote page? Believing Facebook Connect or Like can somehow be Yahoo’s friend in the long run is self-destructively naive.
[7] It’s a navigation column with a kitchen-sink attitude, one of half a dozen other section tabs on top of the page, likely bewildering for most casual users of the site and not quite comprehensive enough for professional traders.
[8] You’d think “customize chart” (unlike other text-links, all lower-case) would allow you to customize the small chart in some meaningful way. Click it and you’re taken to, you guessed it, another page with a completely different, barren UI from the 1950s. It allows you to change nothing but the timespan of the chart to either 1 day, 5 days or 1 year. That’s customization for you, one which was available on the original chart itself to begin with, without having to navigate to another page under false pretenses.
[9] There comes the positively Amazon-ian “People viewing {current stock} also viewed:” inanity. People who love/hate AAPL apparently also love/hate/crave Chipotle and MasterCard. Seriously?
[10] I don’t have access to click rates on that “Trade Now” button, obviously, but I’m guessing those who do click are a small minority. Clearly this linkage to brokers is meant to generate significant origination revenue for Yahoo, but all those broker sites also provide roughly equal or better generic financial info. Somebody who trades at Schwab or Fidelity wouldn’t necessarily be wasting time at Yahoo, while trading.
[11] Also, don’t plan on having more than one broker to quickly go to, since you can only have one.
[12] I’m not entirely sure whether people actually compare brokers at Yahoo! Finance, but even if they do, they get to choose from only four pre-selected brokers, presumably paying Yahoo an origination fee.
[13] Just two articles “featured”? What’s the logic behind featuring random articles here, other than cheap SEO linkage?
[14] One of the two articles “featured” is about RIM’s upcoming BlackBerry 10 phone. I know Eric Jackson has plenty of interesting things to say about AAPL, and does pretty much every single day, but this featured piece has absolutely nothing to do with Apple, the word doesn’t even appear anywhere in the linked article or the accompanying video. It is about RIM, as the title says, a company Apple hasn’t really been competing against for nearly two years now.
[15] (I’m not logged into Finance here but) I’m a proud resident of NYC without a car and yet this is a localized car service ad, from another state. Normally, I’d never see any of these ads, as I use an ad blocker.
[16] A river of news. Really, any text that seems to contain the words “Apple” or “AAPL” can end up here and does. No hierarchy or grouping. The “Filter Headlines” text-link on top takes you to another page with, yes, a completely different, barren UI from the 1950s that allows you to check/uncheck a uneditable list of third party news sources.
[17] Sector/Industry/Sub-Industry categorization of US stocks is an issue for nearly all finance services but, newsflash, Apple dropped “Computer” from its name over 5 years ago. Beyond semantics, this is completely nontrivial for a finance site. Readers shouldn’t be led to believe that nothing more than a small and declining percentage of Apple’s revenue comes from selling “Personal Computers.”
[18] As can be seen in the second column here, Apple’s market cap is 20 times Dell’s. They’re in different leagues and (except for desktops and notebooks) in totally different markets. Apple has stopped worrying about Dell many years ago. Since the title of the section reads “Comparison” (singular), of all Apple’s fierce competitors, Yahoo picked Dell? Furthermore, if you do click the text-link “More Competitors” (plural) you’re taken to another baffling page with random stuff thrown in, but with only a single competitor shown: you guessed it, Dell.
[19] If the stock you’re investigating is an unfamiliar one, wouldn’t it be useful to see what the company does right on top? The “Business Summary” that describes what Apple does is way down. If you were in Wall Street looking for AAPL, it’d be across the river in Jersey City.
[20] “Penny Stocks.” That cheesy ad pretty much says it all.
[21] Live by 3-column layouts, die by trailing, unbalanced empty space.
[22] “Sponsored Links”? Be respectful of the user, just call them “Ads,” especially if you are an advertising company. If you’re ashamed of carrying advertising detritus at the very bottom of your site, 50 feet below sea level, maybe it’s time to rethink the longer prospects of revenue generation at Yahoo! Finance beyond penny stocks and car mechanics?
[23] The long list of data feeders to Yahoo is telling. Yahoo! Finance is obviously an aggregator and not a smart or a handsome one at that. Yahoo doesn’t generate all this stuff, you might say, companies that provide the data feeds to Yahoo do. For a company that wants to “order the information,” that is the problem, isn’t it?
A problem deeper than UI
In the latest quarter earnings call Marissa Mayer gave further indication of how this “ordered information” vision might be deployed:
Overall in search, it’s a key area of investment for us. We need to invest in a lot of interface improvements. All of the innovations in search are going to happen at the user interface level moving forward and we need to invest in those features both on the desktop and on mobile and I think both ultimately will be key plays for us.
If Yahoo wants simply to be the data provider to gatekeepers like Apple, Facebook and Google, it will be problematic since Yahoo is often not the originator of the data flow [23]. General-purpose feed business is not a high-margin opportunity in any case. As the simple analysis above shows when the underlying data layer is decoupled from the UX, especially at the hands of designers insufficiently enthused, the results are mediocre at best. In the long run, it’s difficult to “pretty up” data that you don’t control and derive meaningful profit/benefit from, ask Apple’s Maps team.
And yet, this is Finance, one of Yahoo’s strongest properties, not a minor beta product. It’s enough of an embarrassing UX debacle that I haven’t even mentioned any of the glaring visual design issues at all. No amount of interface pixel-dust will cover up the fundamentally broken opportunity to make financial information actually useful to consumers and semi-professionals, while making money doing it. For the user, it fails the first test: now that I’m presented with all this aggregated information, what do I do with it?
Product design starts right there: What Do I Do With It? Not at picking one of 41 shades of purple. Ordered information is great but hard…repainted information is cheap but insufficient. Here’s hoping Yahoo gets that this time around.
*
P.S. I don’t mean to single out Yahoo here. All the other financial sites, like Bloomberg or Reuters, also suffer from similar misunderstandings of how to make financial information usable and useful. I picked Yahoo because Marissa Mayer appears to be actively revamping various properties, Yahoo! Finance desperately needs TLC and I’d like to see Yahoo come out of its funk if for no other reason than as a balance to Google’s growing dominance in online services. This is clearly a things-I-noticed in-20-minutes kind of a superficial treatment. I simply scanned one stock quote page of one of the myriad sections at Yahoo! Finance. The list of things-that-went-wrong around the entire site must be enormous. It’s also obvious that Yahoo! Finance wasn’t made with passion, focus and much attention to detail, like a lot of Yahoo properties. That said, providing product design analysis from outside a company, without knowledge of its business goals, is fraught with danger So I’ll have to refrain from offering gratuitous advice to Yahoo on how to fundamentally reformulate their web and mobile Finance presence.
