Here's a very recent technique that renders an input string based on analysis of handwriting samples: http://visual.cs.ucl.ac.uk/pubs/handwriting/
1,812 karma · joined May 27, 2011
> Lots of things inside Windows emit ETW events, which is Windows equivalent of DTrace (basically the entire OS, and .NET), it's super useful for debugging performance related events. It's not "Telemetry" like Google Analytics, it's for _you_ to debug your own programs. The easiest way to view the output of them is via WPA, you can watch some videos about it at https://msdn.microsoft.com/en-us/library/windows/hardware/hh...
Disclaimer: I work for m-dollar. My commission rate is 0.0% and VS Code is free, so I am hoping to make it up in volume.
If you have 7-zip installed, you can open the parent directory in 7-zip file manager and delete it from there.
https://visualstudio.uservoice.com/forums/121579-visual-stud...
https://github.com/aspnet/Home/issues/236
http://www.infoq.com/news/2015/04/VB-Core
http://weblogs.asp.net/scottgu/introducing-asp-net-5#after-c...
https://social.msdn.microsoft.com/Forums/vstudio/en-US/22697...
VS Code is a code editor. It has IntelliSense (not text-matched autocomplete, IntelliSense), debugging support, git integration, parameter hints, go to definition, code peek, etc. (http://code.visualstudio.com/docs/editor/editingevolved). The goal is to give you code editing features with the speed and simplicity of a text editor.
They're both free and lightweight, so I use them both pretty much daily.
Excerpt: "For serious coding, developers often need to work with code as more than just text. Visual Studio Code includes built-in support for always-on IntelliSense code completion, richer semantic code understanding and navigation, and code refactoring. VS Code includes enriched built-in support for Node.js development with TypeScript and JavaScript, powered by the same underlying technologies that drive Visual Studio. vS Code includes great tooling for web technologies such as HTML, CSS, Less, Sass, and JSON. VS Code also integrates with package managers, repositories and build tools to perform common tasks to make everyday workflows faster. And VS Code understands Git, and delivers great Git workflows and source diffs integrated with the editor."
The Future of Visual Studio (https://channel9.msdn.com/Events/Build/2016/B859)
Building Desktop Apps in Visual Studio vNext (https://channel9.msdn.com/Events/Build/2016/B824)
My favorite is 0xDEADDEAD
A BSOD isn't interactive, the only thing you can do is search for the error code. Even if users copy down and type the hex code correctly (not at all a given), the search results might be a random ten year old blog post or information about a different version of Windows. The QR Code takes you to an official help page that gives updated, version specific instructions a normal computer user could follow: http://windows.microsoft.com/en-us/windows-10/troubleshoot-b...
I've troubleshot BSOD errors over the phone with relatives. Plain-text error message are a welcome improvement over hex codes.
Important distinction - they're building support for developing Linux-based web applications into Windows, not hosting websites.
It'd be interesting to see an analysis comparing the two. Theoretically, they should be pretty similar, right?
You're welcome to other reasons to avoid C# and .NET, but worrying about their longevity doesn't look like a rational reason.
Seriously, do people even think before posting EEE on every Microsoft open source release? How exactly does that work?
The main benefits, in my opinion, are:
* Scriptable *
For example, here's a script I've used to build a new Windows dev box: https://gist.github.com/jongalloway/ffc3a8c71dfdab4245bc
* Silent, no-BS installers *
Chocolatey packages are supposed to point to silent, no-nagware, no BS installers (specifying the correct command-line args for silent, lightweight installs if needed). Instead of hunting for the right "Download" button, just find the package on Chocolatey.org, maybe check the release history and comments if you're concerned, and off you go.
* Dependencies *
Since Chocolatey is based on NuGet, dependencies are a first class concept. That means that a tool that requires a specific version of imagemagick (random example) would depend on that version, Chocolatey would ensure that the deps are installed first. That has other impacts, such as making it easy to provide a customized version of an existing application (e.g. https://chocolatey.org/packages/EthanBrown.ConEmuConfig) or allowing you to build a meta-package that rolls up several other packages (e.g. "web dev loadout" or whatever).
If you're looking at Chocolatey, I highly recommend Boxstarter, which takes it to the next level with support for all kinds of things you'd want when automating machine builds on Windows: http://boxstarter.org/
Covers things like how he's handling privacy (esp regarding the Ashley Madison hack), scaling, Azure deployment, etc.
Agree, browser user agent sniffing is horrible.
https://github.com/Microsoft/vscode/issues/3182
https://code.visualstudio.com/docs/supporting/faq#_how-to-di...
Also, both the JavaScript language and runtime were pretty hard to build reliable, performant apps in back when Silverlight was introduced. The JavaScript language and runtimes have matured considerably since then.
If it had been my say, I'd have kept it for a little longer than they did, but by now I'd say it's no longer necessary.
There were always two camps in the Silverlight world, both inside and outside of Microsoft: those that saw it as a way to make browser-based applications more awesome, and those that saw Silverlight as a way to get away from that yucky HTML/CSS/JS dev. I was always firmly in the first camp, and from that side of things I wouldn't take back a minute I spent on Silverlight dev - I got a jump on video, vector graphics, browser-based apps, etc., long before it was practical to do that in the browser. When those technologies hit mainstream browsers, great!
Note: Microsoft employee but definitely only speaking for myself here.
Well, anyhow, while at a high level they're both tools that map between database commands and statically typed objects, the approach is very different.
Entity Framework is a full object relational mapper - it's generally the active record pattern, and it supplies things like migrations and entity tracking. The design philosophy is to abstract the database mechanics as much as possible, so you just work with collections of objects (e.g. DbSet<Person>) - add new Person instances to the set, set properties on them, etc. EF converts your intent into database commands (SQL queries in many cases, although EF7 supports some non-relational databases and in-memory storage, too). EF is tracking the state of all your objects, so it knows whether they need to be updated in the data store. That might be fine for a lot of cases - if you're managing a small list of products or customers, working on an intranet app, etc., you're not going to see a difference. I've seen (and fixed) a lot of horrible SQL queries that intranet devs built by concatenating strings; EF is at least going to usually give you decent, secure SQL. (If you're gnashing your teeth right now because EF crushed your dreams in the past, they've done some decent work on SQL generation lately, including some good stuff in EF7). It works pretty well on a lot of apps in lots of dev shops, and can be tuned to work well on big apps if you know what you're doing.
Dapper, and other "micro-ORMs" want to work closer to the metal. Dapper's tuned to taking the results of a database command (SQL query) and populate static objects. There's no entity tracking, state management, etc. Take results of a database query, stuff it into a bunch of object properties, walk away. Because of that, benchmarks showing the performance of select mapping over 500 iterations - POCO serialization are going to run a lot faster, just as (sorry, can't help myself) a motorcycle's going to beat an RV on a race down a tiny dirt trail.
So there may be some slow sites that are running on EF that would be faster on Dapper, but not without evaluating how they're interacting with the database, how they're doing database updates, etc.
Also, to be fair, you can disable a lot of features in EF (or other more fully featured ORMs) and get perf numbers pretty close to micro-ORM's like Dapper. See this comparison: https://github.com/StackExchange/dapper-dot-net/issues/246#i...
However, if you're turning off all the features and hand crafting SQL statements and working with untracked entities, you probably want a micro-ORM, anyways.
My understanding is that the ASP.NET team started at the bottom of the stack and is working their way up. They want to get fundamental HTTP serving basics nailed first. I think that makes sense - they were getting around 170k rps in September, so there were definitely some things to sort out at the basic HTTP serving layer.
Most sites, even relatively high traffic sites, don't serve 50k requests per second.
However, it wasn't granular or modular. For a lot of sites, it was a good balance of features to performance, but in a lot of cases you paid a performance penalty for features you weren't using. That includes the memory footprint penalty - each ASP.NET site loaded up a chunky system.web DLL with the kitchen sink. Back in the day that was fine, but as there are a lot of front-end heavy sites now that use servers mostly as API endpoints, and package managers are pretty standard, devs like to only pay the performance cost (including memory footprint) for the features, middleware, etc., that they're using. That was a big design consideration for ASP.NET Core, and you can really see the results in these specific benchmarks (Techempower plaintext).