This needs a Windows 10 (or applicable "other") option.
484 karma · joined April 13, 2012
I've been fortunate enough to use Durandal a fair amount since, and have found that it's probably 1.5x and 1.5x for a binding or custom element, which IMO is fair for the benefits that it brings.
The existing tuple type doesn't work well because its members are generically named; and very few people want to make lots of little classes that are only used to pass results from one method to its callers.
"When would you use string as opposed to String?" or "Why do you think that the corelib int Convert.ToInt32(double value) method has this name and return type?"
These are more open; allow the candidate to explain that there's little practical difference between string and System.String; that it comes down to coding style; that there are aliases for int to System.Int32, which are probably VC++ showing through a bit (both the fixed size integer types and the underlying problem that made them necessary/useful); that it helps non-.NET consumers know what "int" means etc etc.
IMO it's still not a great interview question though (once you verify that the developer knows the basics) - I think that a lot of devs wouldn't know the ins and outs of this, simply because they'll hardly ever need to appreciate the difference (ie put it in your coding standards that they need to use one and they can forget that the other exists almost entirely).
Off the top of my head, I'd probably consider the following options in order of decending useful/goodness: * Ask for the email address at signup, store a hash, then at reset ask for it again and verify that the hash matches * Ask for/store some other allowed information, then verify that the user wants a reset through that (confirmation code): - Eg collect a phone number and do password resets via SMS/call people who want their password reset - Eg collect a domain and require them to publish a file/txt record that has their email address to send a reset * Give the user some token (eg a specific file). If they can provide the token, allow them to change their password * Get the user to authenticate themselves with a client-side certificate or password. Allow reset only when the user's logged in (ie if they have the certificate or previously knew the password) * Ask for/store some other allowed information, then provide the reset link through that (eg twitter DM or FB account)
The exact nature of your application would probably drive what you would want to do reset-wise. If it's for privacy reasons, obviously some of the ideas above wouldn't work (unless there's some legislation that explicitly excludes capturing email addresses).
What he's probably trying to say though is that miners are likely operating at near break-even, so they continue to mine in the hopes of their luck improving and being able to pay their debts (ie Gambler's fallacy).
There are a bunch of reasons someone would do something illogical. Mining bitcoin is essentially gambling, and problem gamblers will continue to sit and gamble even if they're losing money. (Doubly so if they owe money to someone else).
We have unit tests (fewer on the client than server though), CI that runs integration tests, automated UI tests and other stuff - but that's all much slower than "VS tells me that my code's broken so I should fix it before starting to debug". We'll catch bugs with TS or JS, it's just how long it takes to catch them that's the issue.
Modules aren't so much an issue for us (we don't have a big ball of mud IMO), it's how these modules talk to one another. This is not a problem that we experience in our serverside code because we have powerful tools (in terms of the IDE) that largely stop us from doing dumb things. We refactor a lot, and historically doing this in js has been a massive pain (ie there are no GOOD automated tools for refactoring that I'm aware of). If you use C# and move a method, you expect everything to keep working, but you don't have that same expectation when refactoring javascript. If your app is structured correctly, you do get that with TypeScript.
Same with reviews and training - we have both, but our team isn't big enough to have people dedicated to each area. We mostly hire C# devs, for better or worse, and want them to be as productive per hour as possible. Having it harder to shoot yourself in the foot means fewer feet shot over time, regardless of the team and their skillset.
Getters/setters was an unclear use of term "properties" on my behalf (which actually referred mostly exclusively to methods). Regardless of my personal opinions on getter/setter methods/closures etc, we have established patterns that will take a while to change. The problem is there, and so tooling that helps reduce what breaks when we make changes is a big plus. We don't have a robust message bus in the application, so there's a lot of crosstalk (that's a refactoring area).
And, overall, TS is a superset of javascript so you can always just write JS if that's what you've gotta do.
I guess that my overall point is that javascript is a great language (well, it's ok), but that tools like TypeScript just make things "better" for the average developer working on a large-scale system. JS is an organically grown language, and it shows in a number of places. You can do some super-cool things with it, sure, but for a lot of uses it's a worthwhile tradeoff to write something in a slightly-more-strongly-typed way.
We're about 10% new code, 90% refactoring and updating (though that's a guess, I haven't looked at the stats lately). For us, JS is more painful to maintain than C#. From what we've seen, TypeScript will give us significant benefits on that 90%.
Refactoring and maintaining consistency are the two big problems we have with Javascript. It's easy enough to write javascript that works and does what we need it to do. The challenges come in when you start having separate components that need to interoperate.
eshint/jshint etc take you only so far (preventing you from dumping things into the global scope, avoiding typos). AMD etc can take you a bit further with async loading, and give a better [more consistent] pattern for exporting things than saying to devs "just put your stuff in an IIFE". FB Flow looks helpful, but it's trying to solve a difficult problem, and unfortunately doesn't work so well with our code thanks to ONE bad decision made a long time ago to rely on declaration hoisting ("unreachable code" :( ).
Anyways, knowing that your code isn't going to work before you start spinning up the application saves a lot of time.
Knowing that you can rename a method/function and have no undefined errors come out of it is great. Being able to look up usages of a method across the entire codebase is also useful. Eventually if Microsoft decide to spend resources on it, TypeScript might get CodeLens (which is on its own all manner of cool+useful).
Having class syntax means that you don't need to worry about external consumers accessing properties that they shouldn't be (+gets rid of silly conventions like underscore private members/methods).
JS is a great language, and it's powerful, but when you're writing large quantities of stuff, sometimes you need structure. Particularly when it's a large team and there are people of wildly varying experience, ranging from near-zero JS experience to people who have used it for a decade or more.
The article:
* people are beginning to take bitcoin more seriously.
* there are multiple cryptocurrencies
* bitcoin is the biggest
* namedropping for blockstream
* namedropping for stellar
* ¯\_(ツ)_/¯
* maybe the real competition between cryptocurrencies is still to come
I'm not sure of the message or the point here. My guess would be to namedrop blockstream, but the whole thing is unfocussed and confusing to me.
Because that shit gets the job done. Pick the right tool for the job, sometimes PHP is the right tool.
The plugin support may suck, the dev tools may suck, but in terms of the browser itself, it is much more capable than what they've had in the past.
Still an interesting move from Microsoft. Projects hosted on github, open source, versions of the .NET runtime for mac and linux, embracing docker, node.js and avoiding getting in fights over front end frameworks... this really seems like they're trying to turn a new page.
(source: http://www.hanselman.com/blog/AnnouncingNET2015NETasOpenSour... )
The tooling in Firefox does seem to be improving rapidly (kudos to the devs for that, I'm not trying to trivialise the hard work that they've been putting in, by any means), but there are still several basic(?) features missing from the script debugger. Calling this a "developer edition" is IMO a misnomer until you can reasonably use it to develop pages/sites/applications - currently every other major "not-for-developer edition" browser already gives you almost everything this does, and in some areas quite a bit more.
What would make it a developer browser to me:
* Folder grouping on resources
* Allowing webide or the script web tools tab to work with local folders (Chrome workspace equivalent)
* Dynamic updates to scripts (Chrome workspace/dev tools equivalent)
* The ability to open and/or display more than 1 script at a time. Tabs in developer tools should operate like browser tabs (orderable, poppable etc)
I hope that this isn't just a re-branding exercise - the video, site and fanfare make it sound like Mozilla's aiming to make something great for developers (not to mention that the FF tools are headed in the right direction), but the first release and associated posts/comments seem to indicate that it's essentially a nicer packaging of what used to be aurora.
I'm an Australian who lives/works overseas but spends quite a bit of time in Australia, and it's quite sickening to return every 6 months to a more polarised, racist, and terrified public -- and it's sure as hell not Al Qaeda, Daesh or any other external group that's causing the problems, it's the mainstream media.
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
Sitting everyone down for pictures is almost gloating; but when you remove the obligations, people's desires to be nice, helpful and curious kick in so they take a look and click like.
But yeah, I'm surprised that companies involved in travel aren't all over social media. My only guess is that it might be difficult to change the messaging from "travel is exciting" to "travel with Xyz travels pty ltd is exciting" because of the industry's commoditization.
I'm a reasonably happy Skype user with numbers in a couple of countries and an active subscription. It'd take a lot to get me to switch - my usecase is more expensive/not possible with hangouts. Not to mention that Google seems to always find a way to fuck things up (I have [had?] Google Voice credit but couldn't get paid calls connected in the past).
Skype works, has customer support (?), can sell me things that I want like phone numbers, SMS messages etc. Skype also has some trust because it's their core business and they can't decide to stop offering telephony services one day.
I'd be surprised if a significant portion of Skype's profit came from US-based national calls; and there's nothing overly compelling here for the rest of the world.
To me, this seems like more of an attack on the telecommunications companies, because customers on wifi aren't going to be using precious minutes any more.
I'm definitely curious to see what the paid features will be...
Don't judge based on cost - there are perfectly capable free options in the Microsoft camp too - SQL express, VS express, etc. If you can't do without a higher tier version of VS, you probably have access to it at home through your employer's MSDN account so long as you work somewhere that does use Microsoft. MSFT gets expensive at the enterprise end of the scale, but so does everything. The costs largely IMO are unquantifiable, what's the problem in spending $10k for licensing if it saves you 1k hours of dev time over a free solution? How about a system that can run on 1 server rather than requiring 5, etc etc.
Yes, there's vendor lock in, but you can always move elsewhere later if you want. You're not going to be developing a single project for the rest of your life.
Do what you enjoy, where you enjoy it. Learn how to work in multiple languages and make sure that you're not professionally locked in, but that's different from being technologically locked in on a single project.
* Being able to embed comments which aren't visible to the world is very useful.
* Being able to remove non-important whitespace removes clues on the complexity of generation (though it's a super-complex thing to actually remove only the non-important whitespace thanks to <pre> and CSS styling).
* Linting is another area where things are interesting too. Validators might tell you if your HTML is well structured per the specs, but my js skills and habits have improved as a result of linting. The process might tell you that it's best practice to use readonly instead of readonly="readonly" on an element or similar. Sure, not directly related to minification, but the parsing needs to be done already.
* Minification adds some security through obscurity by making stuff like XSS attacks slightly more difficult (if you use name/id/class mangling). I've only seen this in practice on gmail (most gmail browser addons/scripts break every couple of months when google changes something that alters the generated button ids)
I haven't seen minification done on raw HTML, but have seen non-html solutions used in order to be able to include comments - this is a bit dumb to me.
I've used HTML preprocessors to concatenate separate (single page app) html resources (templates) for delivery, so the pipeline's already there.
If they start confiscating un-poweruperable devices at any scale (ie if it were an enforced policy), that'd make transiting or traveling to the US far more prohibitive (realistically, i'd never transit with my primary laptop; and I'd imagine that a lot of organisations would start allowing their staff to only travel through the US with their China laptops)... ie it sounds like a terrible set of rules to have; and an even worse set to consider enforcing.
edit: I'm Canada-based and travel internationally several times each year -- avoiding the US on these trips is a real inconvenience.
Median salaries are higher, but the standard deviation is lower. Part of this is because the effective minimum wage in Australia is $17/hr. (Benefits are likely more expensive in Aus than the US/Canada as well, particularly if you want to differentiate on giving above average holiday leave etc).
I believe that the article misrepresents facts to make a point that may or may not be there - the type of talent that you'd ideally want to attract (especially as an early-mid stage startup) is likely pretty close in cost to the same talent outside Australia. I'd think that there are more pressing issues (such as the tolerance/approach to failure, or differences in interest rates, which lead incubators to asking for much more equity for less money)...
The other responses show some of the more algorithmically based practical questions. Things like fizzbuzz, quickly followed by how you'd do an in-place string reversal, followed by whether you'd use quicksort vs mergesort for something. Personally, I don't see a huge point in too many maths-based questions because Google, so it's a litmus test and not a skills test IMO.
Then there are language and framework related questions - maybe you'll get shown some complexish code and be asked to spot the bugs. Or you'll get asked how, in practical terms, you'd go about achieving something (with which library would you be working). This would also go over the technologies and skills you might actually need to have to do your job at the company.
To see the cultural fit, they might ask about a project that interested you, and why it interested you. I come from a government town, so this question winds up being pretty awkward, but a lack of passion and enthusiasm is something that I've seen technically-relatively-competent people turned down for.
At a higher level, there's things like "say we wanted to create a link shortener, how would you go about implementing it?" and the follow ups on scaling and asynchronous processing ("what about analytics?" etc.) Stuff which gets you talking in terms of the components and how they'd interact in terms of queueing, designing for reliability etc etc. These types of problems really have no wrong answer, and you can learn a lot about how the developer thinks, their areas of interest, and whether they'd be a good fit for the team without ever getting them stuck on a problem.
At the end of the day, I haven't asked/been asked, questions that are that different from those that you'd ask a junior or intermediate interviewee, it's the detail and quality of the response that you expect to be different.
That said, with 3 hours, they'll probably have the interview and then get you to code something.
The feed returned to normal quite abruptly so I'd assume that there was some censorship around bitcoin-related topics (and I think I've read comments in the past that indicate this to be the case). If this was censorship by HN, then yes, I think it brings a lot to the table. It prevents small groups of fanatics from ruining the site for everyone by promoting their niche interest to excessive levels (which results in lower quality comments anyways).
Well, that's terrible and irresponsible advice to give to anyone who might take it seriously.