Reputation
81,250
Next tag badge:
600/400 score
78/80 answers
Badges
19 191 328
Newest
 Nice Answer
Impact
~2.0m people reached

Dec
27
comment How to license (PowerShell) GUI Projects
@ScantRoger: indeed, reading this makes me think that this question is more off-topic than on-topic, although it's not easy to decide.
Dec
25
comment Should I be using both AngularJS and ASP.NET MVC?
@Natalie: I see. I edited the answer to provide more information about that. A short response is that you mix those two frameworks in projects where it makes sense to have a specific structure on both server and client sides.
Dec
7
comment Steps to begin versioning a web application
@Drano: it largely depends on your current workflow, and the subject is way too large for a comment (and even for an answer). If you do a release every two weeks and the deployment is (mostly) automated, you can move to implicit versions without too much pain. If, instead, you have one to two iterations per year which are considered an important event and requires weeks of manual operations, then your team/company has an important cultural gap to overcome.
Dec
7
comment Steps to begin versioning a web application
@Drano: version irrelevancy and progressive enhancement don't mean the users won't notice that things change. Many features introduced in or (especially) removed from Google Chrome or GMail are noticed by the users; some are expected for a long time, and others are plainly rejected (example: the awful Google Chrome bookmark manager Google ended up removing). What I rather wanted to focus is the paradigm change: instead of waiting for the version 3.4, users expect the new features to appear right now, magically.
Dec
7
comment Steps to begin versioning a web application
@Drano: one of the reasons the users don't care is continuous deployment. If a company is pushing to production several dozens of new versions every day, the very notion of version becomes irrelevant for the end user. The only thing which would matter is the major version, but if changes are implemented progressively, there is no major version per se (Stack Exchange doesn't have one; if GMail does, it corresponds to a purely technical number, irrelevant to the user experience.)
Nov
27
comment Would it be better to have extra checks, or would it be a waste of time?
@NPSF3000: true. I corrected the answer by using multiplication instead. Thank you for noting the original error.
Nov
14
comment What are the advantages of a 'traditional' 'backend' architecture for a standard CRUD app?
@Ginden: that is exactly my point. Is Google Search a client-side application? Well, it does some stuff on client side, but everything of actual interest happens on the servers.
Nov
11
comment What would break if there was an option to make undefined not convert to any other type in JavaScript?
@gman: ah, I see. Well, as I said, the choice to return undefined is valid too. One of the benefits might be is that it's easier to write a conditional rather than a try/catch. Also, it makes it very easy to dismiss a missing element when this is what you want; for instance: product.price || 0.
Nov
11
comment What would break if there was an option to make undefined not convert to any other type in JavaScript?
@gman: you're mixing exceptions and compiler/interpreter errors. AttributeError is an exception which happens during run time. This has nothing to do with an error which will be generated, for instance, by a C# compiler when it builds the IL representation of your code. If you expect JavaScript from throwing ReferenceError, well, that's a choice language designers haven't made. It would be a valid choice, but the choice they made to return undefined looks valid too.
Nov
11
comment What would break if there was an option to make undefined not convert to any other type in JavaScript?
@gman: this is exactly what I was talking about with the JSON example. The dynamic characteristic of JavaScript makes it impossible to determine whether your s variable contains fooBar. If you don't like this fact, dynamic languages are not a good choice for you: in a language such as C++ or Java, s.fooBar will result in a compiler error.
Nov
11
comment What would break if there was an option to make undefined not convert to any other type in JavaScript?
@gman: the linter will point out the error in your code, as I explained in my answer. Your s["in"+"Iframe"] example is irrelevant, since you're simply screwing up with linter/stricter interpreter. It's exactly the same thing that using Reflection in languages such as Java or C# and blaming the compiler that it couldn't tell you that typeof(Product).GetMethod("FindPrice").Invoke(...) will throw an exception because Product doesn't contain FindPrice method.
Nov
11
comment What would break if there was an option to make undefined not convert to any other type in JavaScript?
@Brandin: good point. I edited my answer to emphasize the importance to use a linter, instead of relying purely on auto-completion.
Nov
4
comment Who should read Exception.Message if at all?
@BlueRaja-DannyPflughoeft: isn't it the purpose of logging? You thought about copy-pasting the technical details in Google, because you're an IT professional; ordinary users usually just call their system administrator of blame the software without searching any further.
Nov
3
comment Who should read Exception.Message if at all?
"If the exception is caused by a file system error while you're opening a file, it may make sense to give that message to the end user": but when you throw the file system error, you don't know the context: it might be the user action, or something completely unrelated (like your app making a backup of some configuration, without the user even noticing it). This implies that you'll have a try/catch block which shows a error message, which is very different from showing the exception message directly.
Nov
3
comment Who should read Exception.Message if at all?
@EricLippert: about NullReferenceException, this is exactly why I used this example in my answer to illustrate how performance considerations can make it difficult to add relevant info in the message.
Nov
3
comment Who should read Exception.Message if at all?
@BenAaronson: exactly! I haven't included the file path in my example, since more often than not, this is considered sensitive information, but when not (for instance when it's a web application, where people who will analyze the logs are people who have full access to the application anyway), it should absolutely be in the exception parameters.
Nov
3
comment Who should read Exception.Message if at all?
@Neil: that's a bit too theoretical. In practice, the benefit from hiding the logs from the user are outweighed by the complexity of online logging. Not counting the user friendly aspect. Imagine that you are installing Visual Studio on your new Windows VM. Suddenly, the installation fails. Would you prefer just going to the logs and diagnosing the problem yourself (with the help of Stack Exchange and blogs), or wait until Microsoft solves the problem and publishes a hotfix?
Nov
3
comment Who should read Exception.Message if at all?
@Neil: end users should have access to logs, and exception messages shouldn't contain sensitive information, so I wouldn't mention that as an argument to not showing those messages to end users.
Oct
19
comment I've started, but have never completed an application. How does this affect my employability?
@JᴀʏMᴇᴇ: no, I actually mean show the code of an existent project. This is also what I request from every candidate I interview. This being said, few ones had exclusively projects under NDA and couldn't show any code. Writing code during an interview is mandatory too, but the goal is different; it would be difficult to write any useful quality code half an hour in a stressful, hostile environment.
Oct
19
comment I've started, but have never completed an application. How does this affect my employability?
@douglasg14b: I wouldn't tell those reasons to an interviewer. The fact that you let feature creep or have chosen “wrong” frameworks (or, worse, blame the tool) is not a good sign. You may simply tell that you found more challenging projects to work on, and suspended the previous ones.