If you're new to the industry, then my advice would be a combination of the following... • Try and find evidence that the company you'd be working for has someone highly technically competent. I suggest that your #1 priority if you're early in your career is finding a good mentor. Be humble and try and absorb everything you can from them. It will save you years of learning. • Bear in mind there are (at least) two reasons behind hiring. Sometimes companies just need someone's butt on a seat in order to get some stuff done, to lighten the burden on their team. They hire a junior hoping that they'll get up to scratch soon and then be able to churn through some similar work. This is the most common. Sometimes companies want more junior staff because they find to find someone to invest in for longer term benefit. Which this is, well that's out of your control. But I put it to you that the latter is by far the most beneficial to you personally. Try and quiz the company in interviews regarding the history of the work the department has done, where it's going, why this position has come up etc. to try and figure out which of these you're looking at. I'd recommend focussing on those, and less on the actual techs involved. Technologies change very frequently, and if you're joining this industry, you'll find they continue to change, so being tied to something specific is a risk. I put all my eggs in the Silverlight basket for example. Didn't work out so well, so had to almost start fresh a few years into my career. Keep the attitude of a student throughout your career. You're never done learning, and always try to improve. Best of luck.

Wow, really interesting example. My personal experience has been really positive with Null Reference Types, and it's caught many real world issues long before production, but good to have a cold reminder. I guess I normally consider the point of NRT for me is that it increases the chance that the compiler at least puts the developer to the decision, so if it's a mistake it's a conscious one. This is a good example where that can't be guaranteed. Let me try a counter argument to the IList example, if not only for my own sanity and shrinking NRT world view... So, the null was permitted, not because it was added to a collection of non-nullable strings, but effectively it was added to a list of explicitly nullable objects. Yes, explicitly is not so explicit yet, but hear me out. If you now try and pluck that null object out, and use it where a null is not permitted, I believe the compiler will realise, as your IList is actually IList, so the explicit typing is actually there, and so the compiler will save you at the last minute before the null actually becomes a problem. Based on this I think the behaviour we see is ok and probably by design.

// Warning is generated when you attempt to use it, because underlying type of `object?` is recognised
string s = ilist[0];

As for the array, though...? B*gger, that's scary. Maybe a bug? Weirdly it recognises array as being string[]? after the line it's declared on, but then still does not generate a warning when reading that string? back into a new string. EDIT: Just realised your Console.Writeline bits do demonstrate you reading it out. Are there any examples that don't involve array [] syntax? Maybe it's a bug worth raising?

I used to be a staunch advocate of light themes, but a combination of extended viewing times, the Samsung G9 monitor (which is both incredibly bright, and almost panoramic, so your eyes are blasted from all angles) and increasing ocular migraines has led me to discover that depending on environmental light levels and equipment involved, dark themes can be a huge mercy. Turning the brightness down isn't enough, as you're dropping contrast / dynamic range. I think something like C# in VS looks prettier in the light theme, for sure, but the practicality and comfort of dark theme let me finally give it up.

"they're nullable already surely?" The point is by opting into nullables it makes them NON-nullable by default, rather than nullable by default. I've dived in with both non-nullable reference types and C# 9 records in a greenfield project. A few sprints in and I'm really pleased with how it's influenced / affected the codebase. Records are wonderful for letting details stand out in simple classes, and their immutability drives your design down a positive path. Similarly with the non-nullable reference types, it can be a little jarring at first, but it pretty much just means the compiler can infer more than it could before, and points you to more issues. Sometimes they're "non-issues", that wouldn't really have mattered, but there have definitely been a couple of points where it's caused me to think something deeper that may have been an issue. Null has its uses, and you're not stopped from using it. By introducing Nullable Reference Types into your codebase you're not avoiding the use of null, you're just making it absolutely clear when something can and when something can't be null. And in my opinion that's strong a positive.

The first two I thought of were: 22%: Stigmata (1999) - Rotten Tomatoes[^] (Which unfortunately was 1999, so just missed the criteria) and 35% : The Matrix Revolutions (2003) - Rotten Tomatoes[^] I remember it was the cool opinion to hate Matrix 3, but I remember coming out of the cinema being blown away and exhilarated. I wasn't looking to catch the movie out so I could be cool, I just enjoyed it.

There is something very close to that in Human Computer Interaction (academic field of usability). This article will give you a quick explanation: Visibility, Affordance & Feedback - The Quixotic Engineer[^]

With Silverlight's demise, I've settled on Unity 3D for cross platform games. It's a very different paradigm to Silverlight, but certainly for games it's more powerful. If you're intending on making more (i.e. new games) I'd definitely go with something like that. The HTML export is mind blowing. It's free, and there's a tonne of stuff online to get you up to speed. If on the other hand you just want to port your old game with as little effort as possible then UWP is the obvious choice, as it's still XAML-driven. Yes, you might have to rewrite it again in a few years, but it's probably not that much effort each time.

This is a particularly handy and free (Creative Commons) resource for WPF icons... http://modernuiicons.com/[^]

I understand a number of the participants of the Ludum Dare contest do something like this using Twitch.tv. HTH

Check out my latest article: Hot Shots, my App Innovation contest entry for 2013.

The title says it all, really. The last article I wrote related to a project of roughly 100MB, but understand the current limit for "source code" to be 4MB. This meant I wrote the article on here, and hosted the project files on CodePlex. It's fine really, but downloads don't register on this site & I suspect users would rather not be thrown to an external site to download the files. I've just finished a rather funky Windows Phone app and was thinking about open-sourcing it & writing an article along the lines of "Developing an app for WP8, from concept to certification" but looking at my project size it's 200MB+. Of course these large sizes are down to graphical assets, large open source libraries and so-on but this would seem to be normal for my projects. Getting any decent .NET-like project with a number of graphical assets is always going to be comfortably >4MB. I acknowledge there is a real world cost involved in any storage increase. I also understand that I could include code snippets rather than a whole project dump, but most of the time I think I'd rather offer something another dev can just open up and run. What do people think? Do other article writers find this an issue? Is it common to just store half the content externally?

Check out my latest article: Celerity: How it was all done. A complete how-to on our sensor-driven head-tracking virtual reality tunnel game in C#.

Ooh, nasty! Couldn't see it at first.

Check out my latest article: Celerity: How it was all done. A complete how-to on our sensor-driven head-tracking virtual reality tunnel game in C#.

The moment when you realise your partner of many years is in fact an android. :sigh:

Check out my latest article: Celerity: How it was all done. A complete how-to on our sensor-driven head-tracking virtual reality tunnel game in C#.

Hi, I recently started this article, and edited it over a few days and then published it. As far as I could see it never made it to the Latest Articles bit. Looking at it, it has an "Updated" date set long before the publishing date (even though I updated it just before publishing). :suss: My guess is that when I published, whatever compiles the list of articles for the category looks first at the Created date to see if it's new, rather than the Published date, and if it's not deemed new then then it looks at the Updated date, which is the right idea but doesn't appear to be have been stamped totally correctly if an article's been in draft status for a while. I do accept it's perfectly possible I'm just coming up with an elaborately creative way to assure myself this is why my article seemed to be tucked away from the word go. If it's purely because it sucks then I'll be quiet and I'm sorry! Thanks.

In the beginning there was nothing. Then the lord spoke, and he said, "Let there be light!" and behold! There was still nothing but you could see it better.

Not sure if this is allowed, but doesn't look in the spirit of things when it's for a competition: An author 5-voting himself three times in an hour? [Here]

In the beginning there was nothing. Then the lord spoke, and he said, "Let there be light!" and behold! There was still nothing but you could see it better.

Quote:

...complained about the fact that the checkbox ticks fade in and out when you click on them. Apparently it isn't instant enough.

I had that exact same "issue". I made a checkbox from scratch as a result. :sigh: To be fair the final thing did turn out nicer as a result so I shouldn't complain. :)

In the beginning there was nothing. Then the lord spoke, and he said, "Let there be light!" and behold! There was still nothing but you could see it better.