Isofarro

"The fact that they're involving him at all is a courtesy, a well-intentioned mistake. A mistake I definitely would have made too."

These are necessary mistakes. Better to have tried to get John Gruber on board and failed, than to not have tried.

That way they can always point at the conversation to show that they did try, but Gruber was not interested in collaborating. Otherwise, John Gruber always have the "they stole Markdown from me. They didn't even ask me. I was willing to collaborate." excuse.

It's an open source thing, try to work within the community before forking. Forking is a last resort. This might get to the point where forking is now a reasonable course of action.

"HTML is a document language which is intended to be consumed by machines, whereas Markdown is designed to be good for humans to read directly."

AND intended to be consumed by machines.

For example. John Gruber's markdown perl script transforms his Markdown into HTML.

"The lack of a standard helps keep people honest by making them follow the spirit of the law, not the letter, as you see happening with things like HTML and CSS."

I recognise that line of reasoning from the RSS 2.0 days. And how RSS feeds were okay for years until Dave Winer decided one day that they were funky. Having a deterministic standard is a quality metric.

On Gruber's podcast: he notes that writers should check whether something is valid Markdown by rendering it and seeing the output ( https://overcast.fm/podcasts/episode/344902019595#t=4527 ). paraphrasing his logic: If the output is wrong, that means the input needs fixing. That is an assertion that the code implementation is the specification. And we've been down that road before ( bugwards compatible implementations of Internet Explorer, for example )

Ambiguity is not a good basis for a data structure specification. An undefined behaviour means that all possible behaviours are correct.

The intelligent way around it is to recognise that John Gruber's rights and license, and chose a path that both respects the limitations he puts in place and allows a community to coalesce around a standardised form of a text format derived from John Gruber's spec.

So the intelligent action is to not call it Markdown, since that requires Gruber's written permission, which is currently a time-sensitive issue, and may be a show stopper later as his format slips more and more out of his control.

Pick a new name, document that it's derived from Markdown (and respects John Gruber's wishes), and create a community around the better specified and test-case based approach to standardisation.

Product prefer using derivative libraries, rather than Gruber's own Markdown implementation. (With or without Gruber's written permission). Pandoc, for example, is a common library for Markdown support, I guess GitHub, Reddit, stack overflow are using their own custom implementations, or implementations that started or during their lifetime became custom implementations.

Or keep using it anyway. Most organisations don't actually receive direct Microsoft support/assistance when they run into problems anyway. So Microsoft ending XP support is practically meaningless.

At worst, it allows independent software vendors a small market for regular repeat business. At best, people just keep using XP the same way they've been doing for years.

"If you have built hundreds of thousands of lines on top of a framework,"

Perhaps that wasn't the smartest architecture decision made. Now, don't compound it by rewriting it in the same deeply coupled way for the next shiny framework that sashay's by.

That worked for Smyslov (7th World Chess Champion), who once quipped:

"I will make 40 good moves and if you are able to do the same, the game will end in a draw."

Yuck, just caught it out with:

  e2e4 g8f6
  e4e5 f6d5
  d2d4 b8c6
  f2f4 e7e6
  c2c4 d8h4?
  g2g3 f8b4
  c1d2      -- 2 pieces en-prise at this point.
       h4h6
  c4d5 e6d5
  d2b4 c6b4
  a2a3 b4c6
  b1c3 c6e7

Just a piece down with very little compensation.

I found it quite weak in the opening, well, just about as bad as any chess engine without an opening book to go on. 1. e2e4 g8f6 2. e4e5 f6d5 3. c2c4 d5f4 (weird), 4. d2d4 f4d6. This is probably some opening like the Snake, or the Vulture or something. but beat it quite solidly opening up the f-file and hitting f7 with the queen and rook.

Second game I decided to avoid opening theory and head into a King's Indian Attack. Black's opening moves were sensible, knight and bishops to the right squares, pawns on e5 and d5, but it really wasn't taking my queenside pawn expansion seriously enough, giving up a knight for a pawn. But it's quite resourceful, it's managed to win an exchange, although it's in a desperate position. Currently it's hanging on this position.. oh. No, it's finally crashed. This is the position it died on:

  r . . . r . . .
  . . . . . . k p
  . b q . . . p .
  . R p . p . . .
  P . Q p P . . .
  B N . P . . P B
  . . . . . P . P
  . . . . . . K .

White's last move: f5h3. Took about 10 minutes and made the move h8g7, and then crashed with

  Your move: Traceback (most recent call last):
    File "sunfish.py", line 388, in <module>
      main()
    File "sunfish.py", line 365, in main
      move = parse(crdn[0:2]), parse(crdn[2:4])
    File "sunfish.py", line 345, in parse
      fil, rank = ord(c[0]) - ord('a'), int(c[1]) -1
  ValueError: invalid literal for int() with base 10: ''

So, not strong, but surprisingly strong for the size of the code. Remarkable.

Yep, it's a browser vendor's reaction to a developer-tilted monoculture. On repeat.

On the plus side, User agent strings are moving closer to being useless as conditional branches for features. Hopefully, vendor-prefixes won't be far behind.

I guess developers just don't grok abstractions when it comes to the Web. They know their preferred browser, but somehow fall short of abstracting their development to "work on the Web" rather than "Works best in Chrome on an iPhone 5S."

Smudge raises a valid point. The presence of both the webkit prefixed version and the standardised non-prefix version is adequate. The problem IE Mobile are working around are those developers who have the webkit prefixes CSS properties, but not the standard no-prefix version.

Chrome won't remove them because it breaks these sites relying on the webkit prefix remaining - so there's sufficient ground there to indicate developers are failing. But it's not the developers who include the non-prefixed standardised version.

Yes, there are lots of developers who don't care - the ones who rely on the webkit-prefix support remaining. That is contrary to the spirit of vendor prefixes - experimental CSS properties that should not be relied on.

Those using both the webkit prefixed and the standard non-prefixed versions are using the typical graceful fallback - one that doesn't make other browsers "unsupported"

Just seems to be the BBC homepage. The rest of the site seems to be working just fine: http://news.bbc.co.uk/ for example is working - watching the BBC News Channel right now.

"At least in this web page, the text doesn't go all the way across a 25-inch screen."

You don't have to run a browser full screen on a 25-inch screen. I'm baffled why you give a browser that much space and it bothers you when the page uses it.

Which it acquired itself in February 2014: http://customerexperiencematrix.blogspot.co.uk/2014/02/geniu...

Interesting timing. I would not be surprised if the May launch of genius.com was just something hacked together over a weekend and launched just to push the domain price up.

There isn't much talk about genius.com around the May launch (apart from a bit of press-release marketing). And the focus in acquisition in February leads with LeadRocket, tacking on the brand Genius as an afterthought.

The domain details of genius.com was only switched to CallidusCloud's details in June: http://www.thedomains.com/2014/07/11/rapgenius-com-upgrades-... -- 4 months after acquiring the domain.

Interesting set of coincidences. I wonder when Callidus software knew of RapGenius' interest in the genius.com domain. And their original intentions for it when they acquired it in February.

Looks to be using Google's Keyword tool to get related keywords (or possible latent semantic index scraping).

Two issues I've found after using it twice:

* It returns exact-match like domains, those got decimated in October 2012. (low quality content on exact match domains), and they are proving more difficult to rank related to "keyword over-optimisation" because the keyword already appears in the domain name. Creating content trying not not to overrepeat that keyword in the slug, or path, or content is awkward and unnatural. Better instead to go for a brandable domain rather than a colourless exact match domain

* The suggestions don't take into account trademarks and existing company names. So making domain suggestions of WalmartStock.TLD and WalmartLocations.TLD, and even Walmart.bix is treading in murky territory.

A user disabling JavaScript is only one piece of the no-JavaScript puzzle.

Here are some more: http://isolani.co.uk/blog/javascript/DisablingJavaScriptAski...

"To me it would make more sense to use that time to make the sites usable for visitors with disabilities by including screen reader support and stuff like that."

That assumes the choice is mutually exclusive, and also that we live in a world of perfect delivery and execution of JavaScript.

Progressive enhancement not only ensures core functionality is available regardless of JavaScript, but also when a hiccup of some sort happens on the Web, the user in the process of buying from you isn't then stonewalled.

"The article misses the main point of content delivery network JavaScript: The hot cache."

The stats don't really bear that out: http://statichtml.com/2011/google-ajax-libraries-caching.htm...

and a followup two years later: http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...

these third party CDNs are littered with different versions of jQuery and whatever, so the fragmentation of top sites using different versions seems to dent the chances of having one of these libraries hot cached.

Does Jekyll 2.1.0 still have a dependency on node.js out of the box (https://github.com/jekyll/jekyll/issues/2327)? The release notes don't indicate this has been fixed, and the issue looks to still be open.

Broken on install isn't really a good first impression.

Developers use forEach to apply a function to every element in an array. That is the main use case.

This faster version fails on some arrays (any array that isn't contiguous). This is a bug, not a feature. The library user is now responsible for checking that the array is contiguous before using the faster function.

Is it documented somewhere whether array returning/manipulating functions cause non-contiguity?

And a solid suite of unit tests. The current set looks very light.

I started off at Wits University (Johannesburg, South Africa) aiming for a BCom Accounting, the path towards being a Chartered Accountant. It definitely was the path towards gold.

(And access to cutting edge technology, I remember a friend of mine showing me his new portable computer - in 1993ish, two black padded canvas bags, one containing an all-in-one Mac, the other a portable printer. It was the first time I saw a Mac.)

I was quickly disillusioned by the field, from high school days Accounting was something that appealed to my asperger-like tendencies - a mathematical model of a business, a true answer to the health of the business.

But in a university level it rapidly devolved into picking apart legal statute to find ways of tax avoidance. A game to hide as many debits into pseudo-equities like "Goodwill". That appalled me. I know tax avoidance is legal, but it conflicts with what I believe to be fair and acceptable. That only worsened when I started job interviewing with accounting firms, including Arthur Andersen.

When I see debacles like WorldCom and Enron, I'm not really surprised. And now, tax avoidance schemes like the Double Irish, and the Dutch Sandwich, I'm thankful I am not in that profession.

Seems like a normal case of jet lag. 6000 miles east, +9 hour time difference between San Francisco and Cannes. When the sleep wall hits, it hits hard.

Yes, Amazon have a rule to deploy during working hours, during core hours when engineers are around and available should things go wrong. Also, Amazon is one of a number of organisations who don't deploy releases on Friday.

Not ExpressionEngine per se, but CodeIgniter that came from it.

Thanks for the Craft CMS pointer. I did not spot that when looking for something more modern that supported custom content types last year. I played briefly with Bolt CMS, but it didn't quite feel right to me.

To be a viable web app development model Wordpress really needs to follow down the ExpressionEngine -> CodeIgniter route. Slowly evolving into a set of modular components that work together. (Or how bulky symfony evolved into lightweight symfony2 + components)

Wordpress is still very much stuck in the old-school PHP world: download one big codebase, add some Wordpress specific packages (themes and plugins). That's a far away from where modern PHP is: smaller components brought together with composer and packagist. Which leads to more nimble frameworks for putting together web apps, picking and choosing the right set of components. Don't like Doctrine, use Propel, or RedBean, or Eloquent.

It's okay if your app fits into Wordpress' constraints of the world.

My concerns over the current state of Wordpress as a web-app framework:

* Plugins are special snowflakes, and so raises a gnarly set of conflicts and issues.

* Themes that do a lot more than theming - like WPGeo, which is an entire location-based functionality. It's like there's a packaging construct that involves themes + set of plugins that's missing. So themes become a dumping ground for any code.

* Dependence on global variables (like $wpdb)

* The datastore being SQL is leaked through the codebase.

* The visual layer drives the processing - so themes take control.

* Plugins are wordpress plugins, not well-built PHP packages.

* The extension mechanism (pseudo-event-binding through global functions) makes any code "Wordpress code", it's a lock-in.

* The custom data storage is a joke and inconsistent. serialised php being stored in mysql field, or serialised JSON. Wordpress is missing a mechanism to encourage structured data. I care about the quality of my data, my app needs to care too.

* Unit tests. Wordpress' architecture makes decent unit test coverage difficult.

* The quality of third-party plugin development isn't great. Understandable considering the typical Wordpress audience. If the plugin works, great. If there's a conflict, that can open up a pile of hurt.

* Essentially it's a code-coupling problem. It's difficult to disentangle. So you're mostly writing Wordpress specific code, not componentised PHP modules.

I like the admin interface, I wish that was a separate component that could be forked, and used as the basis for a web app.

I can't see how Wordpress can deal with these issues in a backwards compatible way. Yes, they can create a modular and componentised core that can be packaged up for use outside of Wordpress, but at some point there's going to have to be a shedload of Adaptors to translate that clean crafted and organised code into a bunch of global variables and global functions that themes and plugins rely on.

I can see good bits of Wordpress (like the admin ui) being forked off into separate projects and worked on in isolation to the point they catch up with modern PHP development. But these won't be backwards compatible with Wordpress without a grungy wordpress layer over the top.

Perhaps the damning thing is the lack of a consistent and appropriate data model, backed with a properly structured database. Sure, I can define my own relational database, do by hand what a content management system should already be doing for me - at that point where's the benefit? What if I want to be using a noSQL store instead?

It's hard to justify starting with Wordpress, when there are so many much better frameworks available for PHP that are more suited to packages and componentised code.

First step, up-to-date autoloader and namespaces.

"because Google has now given other websites the ability to destroy your rankings. That just doesn't make sense."

Makes sense to me.

* Take a snapshot of the link graph

* Hit spammers hard with negative penalties.

* Wait for vengeful SEOers to target their competition with negative SEO, and for the search results quality for mainstream users to noticeably drop

* Switch off the negative penalty flag -- Innocent competitors targeted by SEO negative SEO bounce right back

* Compare the before and after link graph.

* Update the list of low-quality link sources.

* Google wins because it has found a lot more spammy link sources than before.

* Spammers lose because their sites drop even further as previously okay link sources are now determined to be spammy

When you play a incomplet-information game with Google, you need to make sure you are not inadvertently providing them more information by changing your tactics. By changing your link building habits because of a negative link penalty, you are giving Google more information than before, you are confirming more link sources are not natural.

The smartest thing you can do is not to be tempted into negative SEOing your competitors. You are only burning the back links Google haven't flagged as spammy yet. So either keep doing what you were doing before the penalty, or stop building spammy back links. But playing with negative SEO plays straight into Google's hands.

At least, risk someone else's private link network, rather than your own ones when doing negative SEO. :-)

"You can negative seo a site out of existence in about two hours and for about $75. It is actually super quick. Once you do it, it can take anywhere from 2 weeks to 2 months for the site to loose it's position or be removed."

This doesn't scale without drawing attention to yourself.

It doesn't scale for an individual SEOer as a repeatable approach to ranking ahead of your competition. Most likely, it's mutually assured destruction - SEOers destroying each other, taking their clients with them.

It doesn't scale across the SEO industry. Too many people take this up as a tool, and the quality of Google search results suffer. That's when Google takes further action.

The one main way negative SEO back linking survives as a reusable technique is if it's used in small unnoticeable doses, and doesn't affect the typical Google user. Because when it does impact mainstream Google users, then Google takes the next step forward.

If the nightmare scenario materialises where SEOers destroy search quality results for mainstream users with negative SEO campaigns, Google flips the "spammy link penalty" off, all those sites affected bounce back immediately.

And then Google will comb through the data they've captured in that time period, and have an improved idea of what link sources are spammy. Google will have a much better idea of the network of sites you used (to benefit yourself before the penalty, and to negatively affect your competition during the penalty). It will stand out.

SEOers are in a classical prisoners dilemma.

"That he stuck to his guns is imo a mistake, that google can be manipulated into dropping sites from their rankings at the behest of others is a serious problem."

There are two main ways of dealing with issues:

* Prevent them from happening

* Mitigate the risk so the fallout is minimised if it does happen

Because there are flaws in the first way doesn't mean the second hasn't been explored or carried out.

We mitigate risk all the time. Seat-belts, looking both ways before crossing the street, insurance. The entire banking system.

So you get hit with a manual penalty for spammy links. Deal with it. Document it in great detail, publish it, share it with Google. Then SEOers will have both the data they need and a Google rep to talk to. Plus, if it is as terrifying as SEOers keep telling us it is, the news headline boost alone will make up for the link profile damage.

I think I know why SEOers are in an uproar about this: they'll have to collaborate with Google on a new level of openness. Effectively, recipients of negative SEO attacks, who then notify Google, will also have a nice shiny Google light shone on their SEO tactics leading up to the negative SEO attack. And I guess almost all SEOers have done something they are not entirely proud of, or wish to be forthcoming about. It's the fear of being seen as something other than completely white-hat.

The ways to avoid reaching that uncomfortable point is:

* Hope their fellow SEOers don't hit them first with a negative SEO attack

* Hope Google reverses this decision, so they don't have to venture down that road.

It's a bit like that Simsons sketch where the whole family are in a shock therapy session:

https://www.youtube.com/watch?v=eP4INdt_-fk

The SEO fear is one of their fellow SEOers pressing the button.

Hopefully it will make them more forthcoming in cleaning up their industry. A bit of public naming and shaming would be nice.

"If there are 10 competitors in your niche (and many will have more like 100), you can do this to five of them at random and google would have no way of determining who the perpetrator was."

For a pure blackhat operation, it would simply be the newest competitor. Blackhatters rarely play the long game, they are used to burn-and-churn operations. They wouldn't have the patience to keep an unprofitable site running.

It's harder when it's a white-hat SEOer who is also comfortable wearing a blackhat-persona, they may have the patience and guile not to make it too evident. Because they know the long term payoff.

"When you report them for paid-links, you wouldn't use your real e-mail address, that doesn't make any sense."

And yet, using an email address that has zero previous visibility / fake-name generated looks suspicious too. Any thing where the sender is mostly anonymous is suspicious, particularly in answering the motive question. (Particularly silly would be using a free email provider, for example)

Again, Blackhatters aren't eager to put themselves on Google's radar, or any public spotlight. Only the naive ones use GMail / Analytics / Webmaster dashboard. They prefer operating behind the scenes and not drawing attention to themselves, because they have lots to hide.

It takes a bit of pre-planning, some good organisation, and a lot of patience to pull off a convincing online profile. Not really the hallmarks of the typical blackhatter.

Of course, if you're into identity theft, are you really willing to risk it ratting out a competitor. And you'll be in organised online crime territory

Plus the downside if the rest of the Blackhat community find out you've been snitching to Google. They may have loose morals and ethics when it comes to SEO, but they have some semblance of respect-earning.

None of this appeals to the blackhatter, seems an awfully contorted process to go through each time just to gain one ranking place (per competitor). Because it's a process that requires contacting a human at Google, it's also not something that's easily automatable or scriptable. Doesn't entirely fit the quick rinse and repeat / burn-n-churn of the typical Blackhatter.

Take out the scare-mongering of negative SEO, and examine what's left. Not much. In the wider picture, it won't even register a blip.

Now, the legal ramifications of someone being caught doing this. Motive and intent, destruction of business value, clear intent to deceive for financial gain. How many more elements are needed for this to be fraud?

Blackhatters may have loose morals or ethics, but they also know how to stay on the right side of the law. And also, not to drift too close towards the organised crime based operations.

Negative SEO won't be a regular tool for blackhat SEOers; too much risk, too much effort to pull off more than a handful of times without being spotted. Organised crime though, for extortion, most likely.

"I don't think it requires any assumptions about Cutts's ambitions, but rather about how much effort it would take an annoyed spammer/black-hat to point some of their tools at the highly visible source of their frustrations."

highly visible only in SEO circles. The rest of the world could hardly care less. It certainly wouldn't make any mainstream news bulletin.

"I think history generally shows that staying one step ahead of criminals/spammers/up-to-no-gooders is a never-ending struggle that does not tend towards positive resolution."

Google are not one step ahead, they are always one step behind, reacting to the next thing. One step ahead is dealing with a problem before it even becomes a problem - in chess they call it prophylaxis - defending before you need to defend.

History generally shows bad things prevailing by people sitting back and doing nothing.

What Google have done with spammy link penalties is to change the game SEOers are playing. It's a classic advice of if you can't win this game, change the game. (Similar to Honduras' World Cup football efforts: if you can't beat 11 men, beat 10).