The author fails to make an important distinction about the people that created the logo.
It's one thing to say that a design agency came in and designed a logo in a weekend. It's another thing to say an internal design team bared down to create a logo in a "weekend" (in quotes, because Marissa may simply be using the term to mean done in a short timespan).
I've worked on both the agency and client side, and the huge difference is that an agency comes in and has to learn very quickly about the client's business (more often than not getting it wrong the first time around) while the people working at the company live and breathe the company culture day in and out. At an agency, you're often jumping between a few clients, but unless you've been the agency of record for a number of years, it is simply not possible for you to have the depth of understanding that an internal marketing team will have. What an agency CAN bring is some fresh outsider thinking not colored by the company's history, but there's no reason the right people within the company can do so as well.
Perhaps the issue is that there is this expectation that everyone should know how to "use" a computer. We forgive older generations, because it's something they never grew up with while being appalled at younger generations because they're not using computers to do technical stuff. News flash: computers are not the end all be all of the world. It's simply an aspect of it, and while some kids won't give a crap about how computers work, others will be wildly passionate about it. Some kids will grow up to be doctors, lawyers, scientists, teachers, artists, philosophers, and excelling in their domains does not come with a requirement of knowing how to connect to a wifi network.
You seem pretty intent on drawing a negative picture of people who can do both design and code, labeling them the worst designers you've ever worked with or a jack of all trades whose ultimate route is some idiot manager role.
There's nothing but benefit for a designer to also pick up some coding skills or a developer gaining an appreciation of design and interaction. And I see no reason someone can't excel at both if they truly desire.
Perhaps the worst designers you've worked with did both, but don't let bad logic lead you to think that the best designers do not.
It takes 10,000 hours of practice to become a good programmer, it takes a similar amount of practice to become a good designer. Yes, if the person spends 20,000 hours, they might be able to do both well. If the designer just learns some action script and never practices, then they aren't really learning to program.
I guess you guys live in a hiring environment where good designer/programmers are easy to hire. For us, just getting good designers, or good programmers, is hard enough. The ones who claim to do both are not good enough at either to make it worth our time. We also suffer from a shortage of good designers compared to good programmers, so dev is always blocked on design and even if designers could code, they would never be given time to do so, they just so many other things to do! After a few years, their programming skills would become stale, and it would just be a waste. You sort of have to practice continuously to keep your skills up.
You may want to check out a program called Divvy. You can set key commands to set the position and size of any window. There's other programs similar to it, but this is my favorite one.
If you can get access to someone's iPhone for 30 seconds you can install a web app that looks just like the iPhone interface but with various surprises when anything is pressed.
The lowest brightness you can achieve by the standard Mac controls is equal to the halfway mark of this brightness app. So this app adds a huge level of control between that lowest setting and pure black.
I'm often unsatisfied with the lowest brightness setting when in a dark room, and this solves that perfectly. I just downlaoded it right now and tried it out and it works perfectly. I'd recommend you do the same as it's free before making judgment on it.
Edit: I just saw your edit, and I think you have it incorrect. Try clicking the brightness app menu bar icon, and then use your keyboard brightness keys to adjust, and you'll see at the lowest setting, it goes to the halfway mark.
In my experience, I would tend to agree that customer service from the government is generally better than corporations, from the DMV (though states my vary), County Clerk Recorders, Passport offices and even the IRS, and they generally seem happier than customer service folk at corporations who read verbatim from support guide trees and are incentivized to do what's in the best interests of the company rather than you.
In my experience of living in four different US states that the quality of customer service in government departments varies from locale to locale and even department to department, just like in corporations. My visit to the DMV here in Texas was quick and easy but the visit to the DMV in Las Vegas was such a maddening experience I'm surprised anyway bothers to get a drivers license in the first place. In the office if someone announced they were going to the DMV we would assume their inability to escape and start looking for a replacement. I heard stories of a guy that got in line as the foundation was being poured for the DMV and he's still there to this day, fifth in line.
Yea, I find the DMV surprisingly helpful. The old saying 'Good enough for government work' used to mean over engineered and built to last, now it's a euphemism for how much you can get away with when outsourcing government work.
I learned this method with the book JavaScript the Good Parts, though it was a while ago and I can't remember the specific reasoning behind the books' recommendation.
From the other commenter's SO link, I found this link to go more in depth into the differences of declaring functions, and it seems to come down to having stricter control on the order of events with no surprises.
I'm not a JS programmer, but I'd say that always using the function expressions (var a = function() {}) is bad. I understand that it's more useful when you intend to manage it as an object, or as part of a bigger object (the additional reasons your first link gives).
But about the hoisting problems... For me, the real problem is that you're declaring a function inside a function. Or using variables with the same name. That's a bad practice, it doesn't make sense. It should be avoided instead of using language constructs to work around it.
That's definitely not in javascript the good parts. It's a new thing and its spreading like some sort of horrible virus. It has quite the opposite effect that you're prescribing to it.
Your second link describes both variable hoisting, a real problem which causes serious problems, and function hoisting that has never been a problem as almost every other modern language behaves that way.
You don't seem to be a polyglot or you'd understand the problem immediately. Variable hoisting is just downright bizarre if you've worked in almost any other language, whereas function declarations can be anywhere in most languages and so when they are declared is almost completely irrelevant to a programmer.
Artificially assigning them to a variable so that suddenly function declaration order does matter is just downright weird. The 'normal' function declaration is better and clearer.
I'm probably not the best person to have a debate about this since I don't have a traditional CS background. I dabble in many different languages, but I'll never claim to be an expert in any.
To your point about this not being in the book JavaScript the Good Parts, I re-downloaded my purchase from Oreilly to double check, and throughout the book, all functions are declared as variables. Here's a screenshot from the second page of the "Functions" chapter, which is the first time a function declaration is introduced in the book: https://dl.dropbox.com/u/1517499/Screen%20Shot%202013-03-26%...
Edit: Just an edit to add that I quickly perused the pdf and couldn't pick out anywhere where he explained why he recommends this way. In any case, I'm always open to any arguments one way or the other.
I don't believe so. It sounds like he prefers using function declations to function expressions. And this is incorrect according to most js gurus. For example:
"b) Function Expressions are more versatile. A Function Declaration can only exist as a “statement” in isolation. All it can do is create an object variable parented by its current scope. In contrast a Function Expression (by definition) is part of a larger construct. If you want to create an anonymous function or assign a function to a prototype or as a property of some other object you need a Function Expression. Whenever you create a new function using a high order application such as curry or compose you are using a Function Expression. Function Expressions and Functional Programming are inseparable."
brings up these disadvantages to function declarations:
* can't conditionally declare functions with consistent results across browsers
* function declarations cannot appear in blocks (technically), though many implementations allow this in practice
finally, i'd argue that function expressions encourage you to think of functions as the first class objects js intended them to be
He included far more code than was necessary, if that's the case. I don't see why the implementation of the function expression would be relevant if so. Clarity would help here.
Why would you want a function called "callback" polluting you global namespace?
What you suggest makes no sense in Javascript. Variable functions allow the developer to simulate namespacing in JS without polluting the global namespace.
If you use jquery, I wrote this really simple snippet that I use for quick down and dirty debugging.
var logit = function(x){$('body').append('<div id=logit></div>');$('#logit').css({'background':'#000','position':'fixed','bottom':0,'right':0,'color':'#fff','padding':5,'font-family':'arial','font-size':'9px','z-index':9999});$('#logit').append(x+'<br>');};
It could very easily be adjusted for non-jquery too.
Then just call it like: logit(whateverYouWantToDisplay);
But what are we gonna use then to open the germy bathroom doors, for the 95-ish% of us who use the paper towel we dry out hands with to also open the door and then drop in a bin next to it?
It's one thing to say that a design agency came in and designed a logo in a weekend. It's another thing to say an internal design team bared down to create a logo in a "weekend" (in quotes, because Marissa may simply be using the term to mean done in a short timespan).
I've worked on both the agency and client side, and the huge difference is that an agency comes in and has to learn very quickly about the client's business (more often than not getting it wrong the first time around) while the people working at the company live and breathe the company culture day in and out. At an agency, you're often jumping between a few clients, but unless you've been the agency of record for a number of years, it is simply not possible for you to have the depth of understanding that an internal marketing team will have. What an agency CAN bring is some fresh outsider thinking not colored by the company's history, but there's no reason the right people within the company can do so as well.