Javascript can't reverse strings
-
Hm, I didn't. I figured since the class page was listing method signatures (which they don't usually) they'd list the revision history as well...
:shame:
-
>"myverylongstring".reverse()
TypeError: "myverylongstring".reverse is not a functionOne of the great fallacies of a language that cannot support a rich editor....
Programmers these days... sigh.
I guess I'll be seeing this answer in interviews.
- Take in user input and output onto screen.
screen.output(user.input)
-
Well, I guess the answer isn't too far off....
Console.WriteLine(Console.ReadLine());
-
-
Take in user input and output onto screen.
Isn't that a bit too simple for an interview question?
-
#include <stdio.h> int main(void) { int c; while( EOF != (c = getchar()) ) { putchar(c); } return 42; }
-
Or, alternatively,
#include <unistd.h> int main(void) { char buf; while( read(0, &buf, 1) && write(1, &buf, 1) ); return 17; }
-
So, where do you start? Everything in PHP is to some degree broken or Discourse-levels of consistent.
You know, I mulled this over while driving... It could actually be useful-ish! I'd actually make it a "Learn PHP" book, with tutorials and all. The main difference being that every tutorial (I think there's enough WTF to go around so we can come up with something no matter which subject is being taught) footnoted with a rant about WTFs encountered.
Hell, if it became popular it'd have real benefits: most would give up, a few that survive would know what the frell they are doing, for the most part at least. That's the hope anyway.
-
Well, there is such a thing as PHP: The Right Way but to my mind it's a bit thin on the ground.
I'd prefer to start with 'this is a thing, here is how to do it properly, and here is the reason PHP fucks you over'.
-
I'd prefer to start with 'this is a thing, here is how to do it properly, and here is the reason PHP fucks you over'.
Exactly what I had in mind. You just put it more succinctly.
-
Isn't that a bit too simple for an interview question?
That just proves that anyone who fails it is probably not going to be a good hire.
-
I walked into an interview for a webapp company without any LINQ experience, and walked out after exploring intellisense in the practice test I was given, with the knowledge to implement queries in LINQ.
I think that's more valuable than actually knowing LINQ in the first place, but meh.
-
The point is, even a trivial test like that will flummox the real ringers, and those are the ones you don't want. Some people get a long way on BS and self-delusion, alas.
-
i like the idea about rants.
anyway, IMO the real problem with PHP it's the PHP dev's.
-
But that only stops them at the door.
Apparently, once they get past the interview door, it's back to people getting a long way on BS and self-delusion.
-
Apparently, once they get past the interview door, it's back to people getting a long way on BS and self-delusion.
You have a better alternative?
-
I think that's more valuable than actually knowing LINQ in the first place, but meh.
It has its uses; a number of ORMs use it quite effectively.
-
No, just disillusioned by business that pretends to like profits, and uses that to explain its unwillingness to make business better, but continues to employ people who make a career out of avoiding work.
-
Not a criticism of LINQ.
Merely stating that the ability to learn on the go is more valuable than knowledge retention.
-
Ah; that makes an insane amount of sense
-
[PHP the right way][1]
i like the idea about rants.
anyway, IMO hte real problem with PHP it's the PHP dev's.
[1]: http://www.phptherightway.com/ "TRWTF"
Yes, that's not a bad start however it only covers the right way, it never goes into any meat about why you don't pull shit.
For example to pick one at random I ended up on Dependency Injection. There is some meat to what it is, the fact it's a good idea and how to implement it but it never gives you a real example of what not to do - and more importantly why.
And also why in some cases not following the rule book to the letter can be a non-terrible thing. Last thing I did, didn't use DI at all. In some cases I might even be persuaded to call some of them antipatterns. E.g. I have a helper class whose job it is to handle image manipulations. There are multiple possible options for actually doing the work and I wanted to abstract that crap away. DI says I should inject something into the helper to indicate what backend I want to use, but in my world, none of the calling contexts should ever give a toss. When my core code receives a file and wants to make a thumbnail, there is no reason why the caller should care whether to use GD or Imagick, that's a matter for the image handler, not the caller, so the caller should not be injecting this, but DI says we should do this to avoid depending on concretions.
Yay.
-
but it never gives you a real example of what not to do - and more importantly why.
And also why in some cases not following the rule book to the letter can be a non-terrible thing.
to be fair, few manuals/books do that. almost all of them try to convince you that they have found the mythical silver bullet. aaaand because of that you get tons of devs believing in dogmas like "Everything must be injected, or you'll be eaten by a velocirraptor"
(feel free to bash my english, i learned it on the interwebz)
-
the caller should not be injecting this
This is correct.
DI says we should do this
This is not correct. Your caller of the image manipulator helper should have that helper injected. The helper should be injected by your DI implementation already configured and ready to go. The DI implementation is the part that knows the dependencies between caller, helper and backend.
-
-
that's a matter for the image handler, not the caller, so the caller should not be injecting this, but DI says we should do this to avoid depending on concretions.
Actually, no, DI says you need to create a factory that will find out which is the preferred backend and composes the image handler with the backend and the caller uses the factory to get an image handler. Of course the caller should have the factory injected ;-).
Sometimes it makes sense. Sometimes it's an overkill. And overkill is an antipattern. 0verkill is much better.
-
-
DI says I should inject something into the helper to indicate what backend I want to use, but in my world, none of the calling contexts should ever give a toss.
If the helper can determine it correctly in all normal cases, there's no reason to make the configuration of the helper something that must be injected. That'd just be forcing a decision they don't care about onto people who don't give a toss, and that's a loser. (An optional property to allow overriding things in the case where the caller does care is OK, but I'd expect that YAGNI if your automatic config code is good enough.)
Remember, whether it is GD or ImageMagick is not generally a dependency in the DI sense. DI is much more about the dependencies between the components (classes, packages, modules, whatever) in your code.
-
My coworkers are still on DI level one:
class view { private DAO theDao; public view() { theDao = new DAO("hardcoded.db.string"); } [...] }
"My code isn't unit-testable, it relies on the database."
-
Yes I know it's not a dependency in the DI sense. Though I can see the case for where it might be.
I have, however, had this very argument recently with someone who was design patterned up the kazoo. More pertinently, "PHP the Right Way"'s explanation seems to suggest you should do it with DI.
In this particular case, I was firmly going for something that abstracted away all the image handling stuff from the other logic because it's really something the caller shouldn't care about. If I add any other of the backend options to ImageMagick (there's TRWTF: there are no less than 4 different ways to get from PHP to ImageMagick, there's Imagick, GraphicsMagick, MagickWand and shelling out to the binaries directly), this smells like it's closer to 'should be injected from calling context' even though that doesn't fit with the intent I have going on.
There are other contexts where I would be building it with DI - but remember also the environment going on does not readily lend itself to DI. I use more classes in any one part of my gallery add-on than that forum system uses pretty much anywhere. So yeah. Fun times.
-
Actually English is one of the worst languages for this.
For example, English has ough, which is the orthographic equivalent of an extended middle finger.
Filed under: The rough dough brought through the bough.
-
For example, English has ough, which is the orthographic equivalent of an extended middle finger.
It's even more fun in British English with some archaic spellings like hiccough (hiccup), hough (hock) and lough (loch) and places like Loughborough (Luffburruh).
-
Loughton - Luff-tun
Broughton - Braw-tonedit: Nope. See below.
-
-
Oops - it's right, it's Woughton.
That's still:
Loughton - Low-ton (like the ou in ouch)
Woughton - Wuff-tun
Broughton - Braw-ton
-
Same happens for American cities.
Woburn - Woo-burn
-
And states - Kansas and Arkansas? Really?
-
"can-sass"
"Ar-can-saw"but then i'm probably mispronouncing them.
-
-
A name that always cracks me up is 'Cockburn'.
As for names on places, how the blazes did the pronunciation of 'Newfoundland' evolve?
-
-
Towcester - Toaster
Bicester - Bister
-
I was going to post Featherstonhaugh (although it's been posted on TDWTF before) but then I also found this Wiki page. Too bad the pronunciation guides are written in that useless IPA format.
-
A name that always cracks me up is 'Cockburn'.
And not one, but two, Twatts:
And one more:
-
How about a wonderful map for your office or break room:
-
As for names on places, how the blazes did the pronunciation of 'Newfoundland' evolve?
Ah, Noofen'land, Canada's Wales...
-
-
"Wooster"
unless my memory fails me.
-
-
hu-uh.
memory has failed one of us.
probably me.
-