HNHacker News
TopNewBestAskShowJobs

Isofarro

3,343 karma · joined April 11, 2010

Technical Architect / full-stack developer
submissionscomments
Isofarro··on Show HN: SEO for JavaScript, HTML5 and Single Page Applications
> On the other hand, if you are building Google Maps, then you should build a web application. Google Maps doesn't work when you disable Javascript.

The "web application" label you use here means what? That it's okay to ignore web development best practices like progressive enhancement, because "web application"?

That Google Maps ignored progressive enhancement is not a good reason for labelling it as a web application.

Is Fix My Street (http://fixmystreet.com/) a web application? It uses a Google Maps type interface so you can report broken street lights, fly tipping:

https://www.mysociety.org/2011/07/08/technical-fixmystreet-m...

> it's an application built completely with Javascript, with no backend support (except for the api that it communicates with).

It's a circuitous definition. Surely an API requires a backend? And surely that API predominantly uses HTTP?

There isn't much difference between returning structured data, and returning an HTML view of structured data. That's just a twiddling of views from a controller (assuming a well-structured codebase). Both deal with an HTTP request and emit an HTTP response, one just does an extra step of rendering HTML.

Isofarro··on Show HN: SEO for JavaScript, HTML5 and Single Page Applications
> the websites of the future will be more and more like web applications, and they need dynamic UI. The thing that's stopping us the SEO problem, which I hope is no longer problem anymore with snapsearch.

This juxtaposition doesn't make sense. If the "dynamic UI" can't be done in a progressively enhanced way, why can it work in a gracefully degrading post-hoc way?

The main point of your software is that the output proves that progressive enhancement was the correct way to build the website in the first place.

Isofarro··on Show HN: SEO for JavaScript, HTML5 and Single Page Applications
> the goal of Snapsearch is to allow the possibility of going full steam ahead with heavy javascript, and not having to worry about trying to make it all compatible with non-js clients like search engines.

The same people who can't build websites in a progressively enhanced way are the same ones that also can't get other fundamental concepts working properly, like:

* Using HTTP URLs in links (or even, using anchor elements as links)

* text-equivalents for non-text content

* not relying on colour to convey content

* Using appropriate semantic structure to mark up content.

There's not much that can be done to save a developer at that point. The best your tool can do is expose more inferior/low-quality content to a search engine (inaccessible in terms of Perceivability, Operability and Usability - since your solution only deals with the Robustness principle of accessibility), after it has been safely constrained inside a JavaScript-mandated environment.

When JavaScript dependency becomes an acceptable starting point, semantic structure, and good markup principles get dumped just as quickly, because they are interdependent.

Isofarro··on Show HN: SEO for JavaScript, HTML5 and Single Page Applications
I'm finding a handy benefit of progressive enhancement is that it forces two distinct server side web-controllers for each piece of functionality - a server-side representation, and an Ajax representation.

That's useful in separating the the HTML generation from the business logic in a way that's obviously evident. So it helps me structure the code in a good clean way.

Isofarro··on Show HN: SEO for JavaScript, HTML5 and Single Page Applications
> Since when are we, web developers, expected to do the search engines' work for them?!

The Web is a trifecta of HTTP, URLs and hyperlinks. That is the fundamental baseline of what it is to be Web. That's what makes it accessible to anyone with a basic internet connection. With that universality comes an overall improvement in education, which improves the quality of life of people on this planet. Not just your little home-town, but the planet.

The Web isn't an artificial intelligence. Not even in the dark days of RDF, respite with logical reasoning engines and ontologies. That isn't going to be your saviour.

So far, there's nothing in the HTTP spec document that stipulates that it requires a JavaScript capable execution. The Web is built to be extensible, which is why techniques like progressive enhancement are just as fundamental. Assume the trifecta of HTTP, URLs and hyperlinks are present and build with that, then enhance with the litany of technologies and shiny toys built on top of the Web stack. Don't just assume those technical building blocks are always going to be there.

So what you are doing, by requiring JavaScript at the HTTP level, isn't Web Development. It's probably more akin to the death-throes of the last Flash developers struggling to justify their existence.

If you need your site to be indexable and searchable, universal, a JavaScript-dependent solution is sub-standard.

These "post-implementation" Javascript static site scrapers, they emulate progressive enhancement badly, because they are backwards. They are about as qualitatively as useful as building a separate accessible website to your main website, you know for them blind people with their talking browsers. It's a band-aid at the point you realised you did not spend the requisite amount of time understanding the environment in which your "website" runs.

And, please, read the full specification of the Google Crawlable Ajax spec before you throw it at me. I have. Including the part that says you really should have built it properly in the first place.

Isofarro··on Show HN: SEO for JavaScript, HTML5 and Single Page Applications
Yehuda Katz, the lead on Ember.js was categorical about the use of ember.js when you require progressive enhancement: Don't use ember.js.

So this is just a case of using the wrong tools for the job, buying the hype without validating the requirements.

Isofarro··on Google is Breaking the Internet
> So then what's the difference between disavows and having the links removed? Getting the links removed costs far more time & money. And it gives Google a data mining stream of feedback they can leverage to dish out further penalties.

That's a good thing right? Pushing sources of bad links down through the basement, effectively nuking the source/network from the link graph.

You know Google's ranking system is based on information, and adding more information leads to better results for the Web user.

Isofarro··on Google is Breaking the Internet
That's where the Google disavow links tool comes in: https://www.google.com/webmasters/tools/disavow-links-main?p...

A model is only as good as the information in it. In this case providing details of these spammy links helps you, and every other site targeted through the same sites/networks/fingerprints.

Consider it a reverse no-follow mechanism.

Isofarro··on Google is Breaking the Internet
The victim site looks at where these newly created back links are coming from, and then reports them to the Google disavow tool and disavow the lot of them. That is the mechanism for dealing with the intent of those links.

After a few cases like this, a long list of multiple disavowed domains/networks/fingerprints, where are these negative links going to come from? This anti-SEO tactic you outline can only be used a handful of times before it becomes useless.

Isofarro··on Google is Breaking the Internet
We were getting a google-shaped web from the moment SEO started optimising for Google rankings.
Isofarro··on Google is Breaking the Internet
> The model (google's algo) should fit reality. Rather than forcing reality to fit the model.

Google's algorithms should reward behaviour that's best for Web users, and penalise behaviour that is worse for Web users.

That way, for people who want to game search engine rankings, they are pushed more towards techniques that benefit web users in the course of trying to benefit themselves.

The problem with models is that they are not accurate simulations of the real world. They have flaws and simplifications, and those give rise to people taking advantages of those flaws. All models and representations have flaws.

Isofarro··on Google is Breaking the Internet
> why can't Google just ignore spammy links instead of penalizing the whole websites and all the websites that link to them

You are suggesting an approach where there are no downsides to link spam. Obviously, players of this game would then ramp up their link spam bots, and run them non-stop. Because it causes no damage to the site they want to rank.

Link spam isn't just a search engine indexing problem, it is also a detriment to the general Web user too. It makes the Web worse, not just search.

Isofarro··on Kasparov Proves No Match for Computer (1997)
Probably the first of only two occurrences where Kasparov's ego-based self-belief collapsed. That mysterious rook move in a drawn endgame spooked him, and seeded the doubt.

Doubt is a costly thing in tournament conditions, doubt about the opponent leads to doubt in your own ability to predict your opponent's moves. So you start looking at more candidate moves at each branch of analysis, and also you start rechecking lines again -- all against the candidate move approach. All this costs time and effort, and tires you down quicker. So weaker patches of play become more regular, unless you buckle down and keep it under control, another source of energy leak.

And over a series of games, in trying to hold that back, Kasparov probably eased off a little in the last game, and committed perhaps the worst blunder of his career, in a line he knew very very well from the other side of the board.

The second time Kasparov's self-belief collapsed was the Braingames World Championship match with Kramnik. But this was less to do with being spooked, and more with the evidence his opponent was far more prepared - perhaps for the first time in Kasparov's career.

Kasparov wears his emotions on his sleeve. A lot of his incredible conceptions are a display of his aggressive creativity and stamina. An emotional battle is one core part of Kasparov's armoury, along with well-prepared innovations and surprises, and his capacity to find aggressive moves that keep his opponent off balance.

I am so impressed for how long Kasparov has kept his game together. Right up to his last tournament in 2006, 25 years playing chess of such quality and magnificence. When others junior to him faded and burned out around him - Shirov, and perhaps recently Morozevic.

And Kasparov, like all chess players, needed to find reasons, external reasons, to explain the failure. In the Deeper Blue match, the paranoia of not seeing analysis printouts from the machine prompted the suggestion that the IBM team were hiding something, like a human grandmaster making that move. It's necessary in the make-up of a chess player to find an external reason, because otherwise it is a clear demonstration of fallibility in tense situations.

(The book "The Inner Game" about Nigel Short's path to challenge Garry Kasparov in 1993, talks a bit about how chess players need to put disasters out of their mind, to be able to play the next game in the match. That ability allowed Short to come out in the next game and sometime produce amazing moves and pushed Kasparov, despite the heavy losses.)

The interesting part of the Deeper Blue match isn't that the computer won the last game, but the human factors of that mysterious rook move right at the start of the match. It set off an emotional reaction in Kasparov, which lead to the spectacular collapse in the last game.

Interesting too is how Kasparov somehow overcame this collapse. Somehow the effects of this disaster didn't seem to affect the rest of his playing strength. He somehow regained complete confidence in himself.

I don't think his match loss to Kramnik was affected by this, Kasparov was just outthought, outplayed, and out prepared by a better player. Kramnik rose to a fantastic level to win that match. Kramnik's fitness for one, was impressive considering his past lifestyle.

Isofarro··on Magento is dead – Merchants want a suite of marketing tools, not refactored code
From the favicon on the site, looked like Drupal.
Isofarro··on W3C EME is not DRM (nor other fear-mongering TLAs)
Sleipnir claims to run on Windows and Mac. Platforms owned by Microsoft and Apple, who coincidentally also own two of the main three DRM implementations (PlayReady and FairPlay). Then Google will add their WideVine DRM scheme.

The difficulty isn't EME, but the proprietary blackbox it interfaces to. Without the blackbox, EME is worthless.

Isofarro··on W3C EME is not DRM (nor other fear-mongering TLAs)
Tim Berners-Lee's statement:

* "[I]f content protection of some kind has to be used for videos, it is better for it to be discussed in the open at W3C, better for everyone to use an interoperable open standard as much as possible, and better for it to be framed in a browser which can be open source, and available on a general purpose computer rather than a special purpose box. Those are key arguments for the decision that this topic is in scope." *

* "Content protection", of which DRM is only one. So the other forms of content protection should still be in scope, and open to discussion

* "better for everyone to use an interoperable open standard as much as possible" -- I can't get my head around how EME is an open standard when the key component that gives it value is a proprietary / licensed / FOSS-incompatible black box.

* "better for it to be framed in a browser which can be open source" -- again, building around a proprietary blackbox can't be the open source solution in spirit. The proprietary blackbox taints the rest of the stack "like a cancer" [1]

* "available on a general purpose computer rather than a special purpose box" -- I wonder what the definition of a general purpose computer is. I worry it's limited to computing platforms owned by Microsoft, Apple, or Google.

* "Those are key arguments for the decision that this topic is in scope". Amen. The technology stack that EME is designing for assumes the answers to these four points, and so seems to reject solutions (e.g. watermarking) that question these assumptions, based in part by confidential agreements between Netflix and the movie industry.

[1] http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_c...

Isofarro··on Amazon's Current Employees Raise the Bar for New Hires
Bezos owns the Washington Post, not the Wall Street Journal.
Isofarro··on Amazon's Current Employees Raise the Bar for New Hires
It depends on which part of the Amazon organisation.

The ones in Amazon Instant Video in London are useless. Particularly in identifying suitable candidates for the AIV Retail Website stack. They've burned out their hiring credibility in London to the point that the three hires to London in 2013 have been from East Europe. Plus churning and burning through university interns. It's been a desperate mess for a good two years now.

I hear positive things about the AWS hiring process.

Isofarro··on Web standards killed the HTML star
You are the only guy that does HTML and CSS (with an implicit: to a sufficiently high quality).

What does your career path look like at that company? Do you actually have a future at that company?

Or have you reached the point where you are perfectly happy doing HTML and CSS until you retire (assuming that's even possible)?

Isofarro··on Web standards killed the HTML star
> "When you're making websites for big clients, you have to deal with things like browser compatibility on every version of IE back to 7 (and yes, it is expected that those rounded borders work on IE7 and render the same as in chrome). You need an HTML star to pull that off."

Or a diligent resetter of expectations. And HTML star should be able to effectively argue against that sort of requirement. Otherwise, what are you paying him for? Markup monkeys are dime a dozen, and there's an A List Apart Sliding Doors article those code monkeys can just follow.

I'd expect more from an HTML star than just knowing how we did rounded corners before border-radius. I'd expect leadership, and standing for correctness.

In both Yahoo and Amazon we succeeded in pushing back against rounded corners in browsers that don't support border-radius. Because that's the pragmatic thing to do.

Browser compatibility doesn't mean pixel-exact layouts, it means that the core objectives of the site are functioning in a customer-supportive way.

Rarely do customers bring up the site in two browsers side-by-side and decide not to buy because the website wasn't identical in both.

Isofarro··on Web standards killed the HTML star
> "none of these things can be learned quickly, and they seem to require many months of experience to actually get right consistently in practice."

That's the same for any language. Especially those that don't just clone the language you already know.

CSS just happens to be the one that takes a structured document and styles it for presentation. Like Latex, like XSL-FO, troff, PostScript. Relatively, CSS is easier to pick up and run with.

Isofarro··on Web standards killed the HTML star
> "The HTML/CSS guru should not exist anyway since the designer is supposed to decide how the page should look like,"

It's this idea that leads to a whole host of trouble. It's the implicit statement that HTML and CSS is just about a visual presentation. A designer (in the typical "I'm a web designer" mould) is singularly unqualified to deliver an accessible experience. Because they cannot let go of the visual aspects, and focus on the non-visual elements. And a lot of that is because Photoshop doesn't support concepts like text-equivalents to images, and tests for whether the page reads correctly in a non visual way.

And then there's interaction design. It's rare to see a web designer have a solid grasp of interaction. Again, because Photoshop doesn't support these concepts.

A static visual representation isn't enough. And so the output from designers with some HTML experience is not enough.

But you're right. The HTML/CSS guru should not exist. But designers are not amenable enough to take up those reins at a high enough quality. And programmers and engineers also seem incapable of generating high quality markup and CSS.

HTML/CSS is where the technical meets design, and neither specialists seems to comfortably handle this intersection. So integration is a pain point.

Isofarro··on We Need Viable Search Engine Competition
Sounds like Yahoo Boss: http://developer.yahoo.com/boss/ And that's been around for years already.

Essentially, you get the Yahoo results, and decorate, filter, reorganise, improve, combine as you wish. So you get the organic results, which you can then innovate upon.

And it has survived the transition from Yahoo-powered search results, to Bing powered search results: http://searchengineland.com/yahoo-boss-moves-from-yahoos-ind...

Which means you have API access to the second most-used search engine in the industry. So what better way to voice your discontent with Google by supporting a competitor.

Running a successful search engine is expensive, it needs continuous investment into R&D. That's why Yahoo took a step back and partnered with Bing instead. The level of investment needed just to hold status quo with the existing market runs into billions of dollars a year, something Yahoo baulked at. Microsoft, however, were still strongly inclined to invest that every year.

Isofarro··on What are you building over the holidays?
Building a website that can help manage/organise/monitor private link networks, or be a dashboard/admin for multiple websites hosted on a variety of web hosts.
Isofarro··on Cheaper to rent in Barcelona and commute to London
Croydon isn't fashionable, I get that. So you need to be happy paying a premium for a fashionable brand. That's all this piece is about, places where there is very high demand and a limited supply are very very expensive.

I have my own 2 bedroom flat in a professional neighbourhood, no through road, so it's pretty much a private community. Paying under £700 a month on a standard variable rate mortgage (I could push it even lower switching mortgage providers).

Looking out my living room window I see trees. In winter, I have views of Caterham valley. It's quiet and peaceful. This morning just the rustle of leaves and my clock ticking away. I'm surrounded by green, rarely hear traffic, a rumble of a train every now and again down the East Grinstead line. It's everything that London is not.

So it's part of Croydon, zone 6. A choice of two train lines, decent access to London. The 40 minute commute each way is good for hacking away at a personal project, laying down foundations for next steps, bolstering/improving unit-test coverage.

Granted, front-door-to-front-door, it costs me 11 hours to do an 8 hour day, but the time outside of that is all mine, in an environment conducive to lots of thinking and reflection, and coding zones.

And earning less than colleagues doing the same role, I have a lot more disposable income as a single tech-guy working in London.

Snub Croydon if you want, but you also chose to justify market prices of North London rent. That's why London has a series of commuter belts running parallel to the train lines. There's a tradeoff of cost, time and quality of life to be made.

I quite like the southern parts of Croydon: South Croydon, Purley, Kenley, Warlingham, Caterham. Croydon has good parts and bad, both can change over time, as people living there slowly change. I'm in a once-family area that's mostly professional couples now. On the commuter belt into London.

Isofarro··on Apple iPad mini. What Rubbish
Angry Birds was released in South Africa earlier this week. Almost 4 years later.
Isofarro··on What you need to know about Angular SEO
Of all the options, the most obvious one seems amiss:

Build it properly the first time with progressive enhancement. Then it will work for all visitors where the JavaScript doesn't kick in for some reason, not just Googlebot and Bingbot.

You know, this: http://digital.cabinetoffice.gov.uk/2013/10/21/how-many-peop...

Isofarro··on How many people are missing out on JavaScript enhancement?
It is what I've suspected for a while, the number of people who proactively disable JavaScript in their browser is just a fifth of that total of people who don't receive an enhanced JavaScript experience

Which means there are other reasons why fully tested and high quality JavaScript fails to run in a browser that fully supports it.

Quite a big chunk of this is probably people using smartphones over 3G network. As Bruce Lawson notes: "Your smartphone is only as smart as the network it's working on." -- https://twitter.com/marcofolio/status/388689216273907712

Also, when network infrastructure companies like Level 3 have outages, yesterday and today, causes JavaScript to fail to reach the browser in great swathes of the United States.

This is all known and understood characteristics of the Internet in general. And why progressive enhancement is the sanest option of dealing constructively in a network a developer does not have complete control over.

And this points again, that JavaScript-dependent frameworks like ember.js, meteor are broken by design, and not fit for purpose in building websites on the Web. They are not designed to work with the strengths of the World Wide Web, but only within a network where every node and connection is controlled by the developer.

Isofarro··on Cargo Cult CSS
You have an accessibility issue in your example markup. Having links adjacent to each other without either non-linked readable characters, or an appropriate markup structure leads to screen readers reading out the numbers 1 2 3 4 in a "linked" tone, and it is impossible to distinguish that from a single link containing all four numbers.

That's why the web development best practice here is to mark up a list of links with a list. And before we had web standards people used to separate adjacent links with the | character, so at least screen readers would have the numbers read out in a link voice, and the 'bar' read out in a non-linked voice.

If your intention is to create reusable components, then it's essential that you're not introducing accessibility issues by default.

There's a second accessibility issue with the pagination. Why is the active page a link? What does it link to, considering that you are already in the view that should be that page. That feels like a link that does nothing. For a generic pagination, this feels like another accessibility issue to trip up developers.

Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL. That leads to developers assuming that everything is handled with JavaScript. It's easy to fix in documentation, by putting in realistic looking URLs in there.

Good examples of documentation are ones that demonstrate good practice, and not encourage bad habits.

I know, good documentation is not easy. That's why we have to be careful of falling into these sorts of pitfalls. Especially when developers have no choice but to rely on documentation being correct.

Isofarro··on Cargo Cult CSS
"A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup."

HTML is HyperText markup language. Hypertext is about links and references to other documents. Links are a first class citizen of a hypertext document. That's about function, not presentation.

← PreviousPage 5 of 15Next →