Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: The plural of anecdote is not data however (Score 1) 96

by Afty0r (#49509475) Attached to: How Uber Surge Pricing Really Works

my experiences are very different to the stated outcome of the analysis that "It does not put new drivers on the road."

I use Uber fairly regularly in London with friends (more than monthly compared with perhaps annually for "Black Cabs" prior to Uber) and I often chat with the drivers about their experiences, financial impact of uber etc. because my father is a cab driver in a city which does not yet have Uber and I have a vested interest.

When I ask about the surge pricing, every driver without exception has told me that he works around "chucking out time" (common bar closing time in the UK) more than he normally would because of surge pricing.

The methodology the author (above) uses seems extremely suspect, and I cannot agree with this conclusion that it doesn't put new drivers on the road. He seems to think that as soon as surge pricing activates, that magical drivers will appear from nowhere within 2-3 minutes - and if that doesn't happen he claims "it's not working". He is missing a MASSIVE factor here (that also affects taxi cab drivers other than uber) which is that demand is predictable - busy late-night areas, concert and sporting venues at the end of events etc. are known to be busy well ahead of time. The number of drivers in that area at that time would not be so volatile as to immediately increase when surge pricing kicks in, but it is highly likely that the number of drivers in the area *before Surge Pricing even kicks in* is way way higher than it would otherwise have been.

For example: A good taxi cab driver will choose to be in predictably busy areas a while before they get busy...

In conclusion, author sucks. Source: family in the industry, and analytical/logical brain.

Comment: Trade-Off (Score 1) 892

Reddit is probably going to get quite a bit of PR for this - they're also not going to be employing many people who have strong negotiating skills. In the short term they get to resonate a message with their audience, in the long term they lose a lot of competitiveness, especially in their sales and procurement departments.

Not a tradeoff I would be willing to make if I was concerned about the long term viability of my business.

Comment: Re:Tabs vs Spaces (Score 1) 428

by Afty0r (#49427747) Attached to: Stack Overflow 2015 Developer Survey Reveals Coder Stats

Could you elaborate on this for me:
"Because tabs are not enough to lay out code well (you always end up with a couple of spaces to align things correctly)."

Each tab indents X spaces - it's just a multiplier. You talk about using a "mixture" causing problems, and I would agree - so why not stick with tabs which are more flexible, configurable etc?

Using spaces requires additional keypresses, and also requires that the code display with the same indentation on my screen as it does on my co-workers. With tabs he can have the huge indentations that he loves, and I can have the small ones that I love, allowing us both to read and comprehend code more quickly.

Comment: Re:Tabs vs Spaces (Score 1) 428

by Afty0r (#49427743) Attached to: Stack Overflow 2015 Developer Survey Reveals Coder Stats

I had to address this:
"If you avoid tabs and use only spaces, OTOH, the code formatting will look correct on any editor with any tab setting."

Different people have different reading styles, there's rarely such a thing as "correct" (well, perhaps in a company with a single set of coding standards, but they're not the same everywhere). I love the fact that with tabs both I and the guy next to me who loves to indent everything about 87 lines can work on the same code-base and I can actually read it because each tab indents 2 characters on my screen and 6 on his... so it looks "correct" for both of us, using the same source code.

Comment: Tabs vs Spaces (Score 3, Interesting) 428

by Afty0r (#49425963) Attached to: Stack Overflow 2015 Developer Survey Reveals Coder Stats

As a fairly experienced and slightly wrinkly and grey developer, can anyone tell me why spaces over tabs?

Tabs allow the developer to customise their IDE to display the amount of indentation they desire... and use fewer bytes... spaces seem to have no benefits whatsoever in my book.

Comment: Re:Unpublished (Score 1) 278

by Afty0r (#49396585) Attached to: 9th Circuit Rules Netflix Isn't Subject To Disability Law

It would suck if the plaintiff won. I love captions, and am glad that Netflix recently added them, but if Netflix lost this case then anybody with a business website would be required to make their site compatible with screen readers, etc. That's a good idea in principle, but to require by law everybody to do that would be insane.

I'm a web developer, and there are already fairly strict requirements about catering for various disabilities if you are writing websites for the public sector (varies by jurisdiction/country). The private sector not so much - but it would not be a particularly onerous burden if the requirements were reasonable - it would add a small additional cost to the cost of producing most websites, but then all disabled people would be able to partake in the web ecosystem, I suspect it's (mostly) a price worth paying. There might be a small hump in prices while the masses of weaker web developers had to learn some new techniques, but ultimately it would become standard, and built into frameworks and process driving the price down close to zero.

Many years ago people used to say things VERY similar to your sentence about disabled ramps/toilets etc. for access to premises - "the cost would be enormous to fit out every building for the disabled!". Yet now in my country almost all businesses must provide reasonable assistance both to disabled employees and disabled customers. I think you would find it difficult to find someone who would now argue that that this requirement was a "bad thing".

Comment: Re: Sooo .. (Score 5, Informative) 127

This is one of the most common forms of phone theft these days - not the traditional "violent mugging" but the most basic form of physical robbery - grab it quickly out of someone's unsuspecting hand as they walk down the street focussed on their phone and not the world around them. Then run or bike away. I haven't known someone have their phone stolen in a "mugging-style" robbery in many years, but I personally know of four people (in London) who have had their phone stolen by this method recently.

Comment: Re:HTTP isn't why the web is slow (Score 1) 161

by Afty0r (#48774733) Attached to: HTTP/2 - the IETF Is Phoning It In

loads untold numbers of scripts and other files from dozens of domains, mostly for tracking, A/B testing and other things that the user doesn't want or need

I know this is a popular meme around here, and on the tracking side I am kinda with you (though it is nice to have ads which are more contextually relevant to me and this can help) but on A/B users DEFINITELY want and need this... it's a fantastic tool in making web sites better over time - meaning all users benefit from continued usage.

Arguing against A/B testing because "you don't want it" is like arguing against some of your taxes being used in medical research to cure disease - just because you are not getting a benefit today (you're actually LOSING money) does not mean it is a bad thing, or that you should attempt to not participate.

(as an aside, we still live in a world where many senior people with zero knowledge of website usage and user experience architecture still think they should be dictating layout/flow/features/content - and you cannot hit these people round the head with a clue by four... A/B testing is useful to show up their shitty ideas for what they are and keep the sites good).

Comment: Millionaire who can't do math? (Score 1) 329

by Afty0r (#48491749) Attached to: Taxi Medallion Prices Plummet Under Pressure From Uber

"I'm already at peace with the idea that I'm going to go bankrupt," said Larry Ionescu, who owns 98 Chicago taxi medallions. As recently as April, Boston taxi medallions were selling for $700,000. The last sale, in October, was for $561,000.

Larry believes he will go bankrupt, Larry who owns assets which he could liquidate for around $55 million - so unless he has debts of over $55 million or one CRAZY hectic lifestyle, he cannot bankrupt unless he's 2 marbles short of a jar and chooses not to liquidate now. If this is the case, then he's an idiot and I have no sympathy. And if either of the former are true, I still have no sympathy.

Comment: Re:Flawed, 'cos... (Score 1) 454

by Afty0r (#48448421) Attached to: In a Self-Driving Future, We May Not Even Want To Own Cars

2. Consumers want reliability and 100% availability. Consider Uber and Lyft that promise this, except during surge pricing periods. People hate this. It's economically correct in the case of Uber and Lyft, and an obvious idea, but surge pricing during rush hour isn't going to work. People will still own their own cars.

It depends on the alternatives (public transportation, flexibility of demand to go one hour earlier or later, and telecommuting etc.) but surge pricing makes a whole lot of sense. Especially when working on a scale where the surges will be known in advance, can be pre-booked etc.
It will be fine to charge 2x the "base price" for an 8.30am commute if that is what people are expecting to pay. Current hostility to surge pricing seems to be based mostly around the lack of clarity as to the actual price.

3. Personalization and customization. Hey, I like my cars stock, but I still have my stuff in the center console, my presets on the stereo (yes, 760 am in the morning, I'm a dying breed), and my iPhone paired to Sync.

This is already partially solved, Spotify will sync with your uber to play your desired party playlist on the way to the party. In the future, this kind of interoperability will become more ubiqitous.

4. Toy haulers. You're not going to call Uber or Lyft to tow your trailer to a state park or tow your boat to a launch. And this isn't 99%'er speaking, this is blue collar worker in my part of the country.

While some very specialist tasks might not be suited to a "time share" model, as the world moves to such a model it will become MUCH more economically costly to run your own vehicle - so the price point at which a specialist time-share service for minority use-cases will move down significantly.

Comment: Re:Testing (Score 1) 212

by Afty0r (#48358021) Attached to: New Book Argues Automation Is Making Software Developers Less Capable

projects are FLOODED with automated testing tools to ensure their code works. And sure enough, every bug that I submit has an "automated test" that didn't test that particular condition

THIS THIS THIS

As a software engineer (now half-suity) of twenty years, I am constantly frustrated by those newer to the profession who got caught up in the whole "Unit Tests are Sacrosanct" philosophy. I have worked with multiple engineers who value "testability" over "working".

Unit tests are convenient, a handy tool for programmers, but in my experience they have close to zero inverse correlation with the number of bugs in the programmers output. Any programmer who can think of the right cases for his unit tests is also capable of considering those same cases when writing his code - the correlation between [Experience and Ability] and number of bugs is the biggest one out there.

Know what I favour? Readability and simplicity over pointless abstractions. Functioning, working applications over "90% code coverage". Things that fail at compile-time over things that fail at run-time. And when I press these principles onto more junior devs I always get push back about how "that's old fashioned" or "that needs extra lines of code" - they seems to complete disbelieve, and then they wonder how the hell I write and manage multiple web sites in my spare time that are generally more complex and reliable than any of the commercial sites I've worked on (with one or two notable exceptions).

KISS applies to everything, and unit tests do not adhere to this principle. They have a time and a place when they start to show their value - and that time and place is when SOME of the following are true:
-] Codebase is expected to be maintained by a large team, or eventually by persons who were not involved in building it
-] Codebase will be architected by senior staff, and then maintained by more junior staff
-] Codebase may be sold to, or extended by, third parties (open source is big on this)
-] Codebase is difficult to read/pick-up and has high levels of abstraction
-] Codebase is expected to change significantly in the short or medium term
-] Team involved is junior or inexperienced in one or more significant factors (in general, language, app domain)

Outside of some of these scenarios (I may have missed some, please do comment) you should be seriously considering how much of your investment you place into Unit Tests. I have seen some companies/teams/individuals spend more time writing unit tests than they did functioning code - that's negligent in some cases. If your team had double the velocity on new features by simply writing features instead of upping levels of code coverage, your company/owners/shareholders would have twice their return on investment...

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...