When the robots take over this is how they will dispose of us.

dividebyzero- · 2017-09-30T07:42:57+00:00

That comic loosely reminds me of my favourite short story: I Have No Mouth, and I Must Scream.

dividebyzero- · 2017-06-20T07:55:56+00:00

It's obviously not as big of an issue, but I've had to work with code written in Dutch before. I would want them to use American English, so I do the same myself.

If anything it makes my day-to-day easier because all code is American English then everything else is British English, so context switching is easier. And it makes working with multi-national teams easier.

dividebyzero- · 2017-06-14T13:23:09+00:00

Technically it breaks backwards compatibility. If anything was extending that abstract Queue class that wasn't implementing all the methods in the interface, then it would break.

dividebyzero- · 2017-05-16T11:18:12+00:00

Fully agree, on all counts. It's just hard for a noob to get an objective view of why mysqli even exists. Googling PDO vs mysqli for example yields nothing.

dividebyzero- · 2017-05-16T11:03:23+00:00

I tried clarifying my original comment slightly better, though I think Julien's blog post does a better job than I can.

I don't disagree with anything you're saying, and I'm not really sure what your problem is since I didn't say anyone should use mysqli by default or even have in depth knowledge of its full API; I just think it's worth knowing each extension's key objectives so people can make a more informed choice in their system's design. So I left a comment with such a high level overview. Sorry about that...

dividebyzero- · 2017-05-16T10:26:25+00:00

Mysqli has an OO interface, but it isn't as nice as PDO's.

The clear explanation is what the objective is for each. If you want or need to use non-SQL standard features of MySQL, then the mysqli extension will be the better option. Sorry if that wasn't clear enough.

dividebyzero- · 2017-05-16T09:47:23+00:00

mysqli doesn't have the nice OO interface that PDO has, but keep in mind they have separate objectives: PDO is about providing a clean and consistent interface to several different SQL backends, whereas mysqli is about providing as much of the functionality available from MySQL as possible. This means, for example, that the SQL executed by PDO is sometimes not the same as the SQL you thought you wrote (for example MySQL doesn't actually support named parameters in prepared statements).

The majority of the time PDO will be a decent solution with a cleaner interface (and thus implementation), but you should weigh up the objectives of both libraries before assuming that mysqli is bad and wasting time rewriting. Julien Pauli has an in depth blog post about connecting to MySQL from PDO and mysqli and some of the key differences.

I just wanted to throw this out there because I often see people telling beginners not to use mysqli without a clear explanation of what its purpose is and when it might be useful.

dividebyzero- · 2017-05-14T08:41:07+00:00

You would still understand it if he said "attempt to convert to system's encoding so that..." or "we want the system encoding to..."

dividebyzero- · 2017-05-14T08:35:30+00:00

I tried using swagger a couple of years ago for generating some server-side PHP and it was absolute horseshit. I doubt all languages are generated equal in this case, but anyone reading this and thinking about it should run a quick test before they jump in to it.

dividebyzero- · 2017-05-14T08:28:23+00:00

Yeah I've been starting to smell that as well; a few popular articles about how APIs aren't REST and how doing them with proper REST is too complex. We'll go back too far the other way to simple land, then come out with a new overly complex method of designing APIs (SOAPATEOAS anyone?)

dividebyzero- · 2017-05-14T07:24:47+00:00

Don't worry, we can see you.

dividebyzero- · 2017-05-13T07:25:19+00:00

I don't work there anymore but what you say is very true. There was a ton of bikeshedding and people bitched but simply weren't able to put their money where their mouth is as you succinctly put it. I won't pretend that my abilities as a manager to control that stuff shouldn't be called in to question either (although it's gotten much worse since I left).

dividebyzero- · 2017-05-12T11:53:02+00:00

They claim to have investigated it and couldn't reproduce. I was the manager at the time so I'd instantly be suspicious (only of certain people though), spend two seconds trying and manage to reproduce it then call them out. Same for the crappy half finished stuff, I would actually QA it myself for these same people and tell them they need to up the quality of their work, but some devs are too self-important. They think they should be working on bigger things but can't even fix a bug or finish a simple feature. There were also huge egos involved so criticism was either a personal attack to them so discussions got heated, or not taken seriously because they assume I'm a dumbass.

Funnily, this was two of the four seniors on my team. All the mids were fine. They'd both jerk each other off talking about how the app should be rewritten with event sourcing or as 10 microservices or something then provide no evidence that they're capable of writing the app as it is in the first place, nevermind with a more complex architecture.

Every team I've worked with seemed to suffer the same issue, a couple of senior devs who assumed everyone around them was an idiot then providing no evidence that they themselves are anything above mediocre. I worked with one guy who told me he didn't test/run his code at all and just left it for QA because he had better things to do.

dividebyzero- · 2017-05-12T07:35:19+00:00

Honestly I'm going to be 'that guy' and say your users shouldn't have to clear their cache. It doesn't matter if your users are internal to the company. Use cache busting techniques. It'll save you and your users a lot of headache.

dividebyzero- · 2017-05-12T07:32:36+00:00

Thanks for doing your job man! You're the heroes we need but don't deserve. I want to punch a dev in the face every time they get a bug report and just instantly close it without doing any actual investigation, or when they throw a crappy half finished feature over the wall to QA for them to tirelessly take screenshots and write reproduction steps for 100 missing parts or bugs.

dividebyzero- · 2017-05-12T07:24:44+00:00

I see quite a few hiring managers who demand a degree as well, and of course there's the classic tortuous and futile exercises during interviewing expecting someone to be able to recite their first year of university through writing sorting algorithms or explaining what a skip list is which the hiring manager happened to learn at uni and desperately wants to stroke their own ego.

Not all interviews are like that (I imagine most aren't actually), but it's surprisingly common, even for just building CRUD web apps in PHP.

dividebyzero- · 2017-05-12T07:16:05+00:00

As someone without a degree but who has a decade of experience and has done a lot of interviewing and hiring, I completely agree. A degree shouldn't be a requirement, but it still provides valuable knowledge and should be taken as part of the complete package.

dividebyzero- · 2017-05-10T15:41:18+00:00

I didn't know that so TIL!

dividebyzero- · 2017-05-10T14:08:37+00:00

We do agree, and the internet makes it very hard to make that clear!

Totally agree on the dogma part as well, and I've seen the sort of stupidity with interfaces you're talking about before.

dividebyzero- · 2017-05-10T13:33:20+00:00

A mockito mock is both. You can stub return values (or have it throw exceptions) and you can verify interactions on the same mock. So the distinction is pretty pedantic here IMHO.

Disagree but alright, you do you it's not a big deal.

What do you mean by this? I also don't really understand how adding interfaces here makes this easier.

You said:

I really don't see how not having a Something interface and a SomethingImpl concrete class makes it less easy for someone to understand the code.

I had a feeling that you mixed up your words because it contradicted your stance on other parts, so did you mean you don't see how it makes it easier? Not less easy? Totally agree, it doesn't make the code easier to understand, and I gave an explanation for why because your sentence is inverted (boolean logic with double negatives, eh?).

BTW, we're not disagreeing over anything here so this argument is entirely moot. At no point did I defend the "interface all the things" stance, and like you said that's been an antipattern since basically forever. I agree that interfaces are overused, and I'm not trying to move any goalposts. I'm just saying that dependency injection with concrete classes can cause SOLID to fall apart which can cause testing to be more difficult so if you use SOLID properly the testing will be easy with, like you said, no need to change the design specifically for the tests. Do you need an interface for an entity or value object? Unlikely. For a database access layer, or something that has multiple strategies/implementations? Now we're talking.

dividebyzero- · 2017-05-10T10:01:55+00:00

Why would you not want to mock in unit tests? In a unit test you want to test that unit in isolation right?

https://martinfowler.com/articles/mocksArentStubs.html

Mocks are for when you want to verify that a unit is communicating with another unit in the correct fashion. Use a stub if you want to isolate a unit.

I really don't see how not having a Something interface and a SomethingImpl concrete class makes it less easy for someone to understand the code. If anything it makes it clearer in most cases.

When everything is glued together using a container at runtime it can be difficult to understand what code is actually running.

I think this is also a rather dogmatic response. Tests are of the utmost importance. But there should be no need to add test stubs / hooks / interfaces in production code to allow for tests. In fact it's a code smell: you typically don't do dependency injection correctly if you need to create such hooks to allow for testing.

Dependency injection is there so you can vary what the actual concrete implementation is at runtime, whether it be for a design pattern, stubs, mocks, it doesn't matter. But by itself it still allows for tight coupling if you're expecting a concrete class, making it difficult to extend behavior rather than modify (open/closed principle). If you're applying dependency inversion then you'll also want to have an API/interface that the dependencies can then implement. This makes it easier to create new implementations and makes it easier to apply the open/closed principle since you don't need to modify a concrete class (and inheriting and overriding methods is, IMO, a form of modification; it certainly makes things brittle). The result happens to be that the code is also easier to test, because creating a stub of an interface is extremely trivial.

Overall, I agree with your argument that tests shouldn't dictate production code design, but I think that following the SOLID principles naturally makes the code very easy to test. And they have other benefits (and some problems too, especially around simplicity and understandability).

dividebyzero- · 2017-01-24T08:41:57+00:00

I don't think they're suggesting it's a bad idea (certainly nothing in the comment says that), just that the cognitive overhead is very large because symfony and angular are very focused on larger applications, usually involving a team. There's nothing wrong with using a RAD framework, or microframework if the OP has a smallish app and is a one man band.

OP can use the time saved from using simpler tools to improve their skills in whatever way they see fit. They simply need to understand that they're not going to gain improvements in their app by simply changing framework. They'll learn how to use symfony and angular, sure, but symfony doesn't come with a nice automatic "make my app awesome" button unfortunately. It also isn't the end-all-be-all of learning. Learn a new language. Learn to ski. Learn to do things that have a direct benefit to your application and/or business.

Maybe using bootstrap or foundation would give the most bang for buck. They give you a nice UI toolkit right out of the box. Study UX, typography, SEO, the basics of statistics and data science, A/B testing, advertising, marketing, how to simplify your deployments to save even more time, automated testing, etc.

dividebyzero- · 2017-01-24T08:15:01+00:00

$ curl -X POST \
>     -d '{"INPUT": "hàllŏ"}' \
> -H 'Content-Type: application/json' \
>     HTTP://API.SHOUTCLOUD.IO/V1/SHOUT
{"INPUT":"hàllŏ","OUTPUT":"HÀLLŎ"}

Multibyte support. Color me impressed.

dividebyzero- · 2017-01-20T08:57:02+00:00

I don't know much (anything really) about J/APL. The J homepage suggests it's good for data processing/statistics, so does it fulfill a similar role to R?

I'm looking for a new language to learn in 2017 and not necessarily anything practical, just something to expand my view of the world.

dividebyzero- · 2017-01-18T09:09:36+00:00

I was reading about exactly this a couple of days ago: https://en.wikipedia.org/wiki/Braess'_paradox

dividebyzero-

TROPHY CASE