Note: the Go to navigation is available since VS 2010, you only need to set the shortcut.
Integration of style-cop-like rules seems ok, my only worry is that all those features will make VS sluggish.
And that braces refactoring seems a poor example. Either you are a member of your team, and you don't write code without them, or it's some old code, that shouldn't be automatically refactored if the refactoring is the only goal.
> Integration of style-cop-like rules seems ok, my only worry is that all those features will make VS sluggish
They really shouldn't. We've actually spent the majority of our time in VS2017 on perf. So even with all the extra functionality, it's significant faster and more responsive across the board.
One thing that helps out here is that we don't run any of this analysis in the core VS process. As such, we are not contending for any resources that VS itself needs. i.e. a large source of hiccups in VS was due to the GC having to run right when a UI request was coming in. By moving this analysis out of proc we dramatically lighten the memory load in VS and we make it so that the GC runs less often, and takes less time. This clears up the UI thread more and makes things much more responsive.
> Either you are a member of your team, and you don't write code without them, or it's some old code, that shouldn't be automatically refactored if the refactoring is the only goal.
Or, you're a team that has decided on new, more stringent, coding requirements. And now you want to find and fix up all the violations. Or you're absorbing code by a different group with different coding patterns. Or, you just missed something during a code review and you want to go fix it up :)
If teams have a style preference, then it is definitely valuable to have automated tooling checking to ensure the style is maintained. Otherwise you're shifting the burden onto the team members, which is precisely what tooling like this is supposed to alleviate.
> And that braces refactoring seems a poor example.
NOte: we've added many style options in VS2017, and we're going to continue adding more. Options include:
1. Do you want field/property/methods/events qualified with "this." or not
2. Do you prefer predefined types (like "string") or do you prefer the .net fx types (like "System.String")
3. How and when do you use "var".
4. Do you want to use => for simple properties/methods/etc.
5. Would you prefer to use the more concise typechecking constructs over the previous approaches for type-checking.
6. Do you want to use ?? or ?. when applicable
Sorry - but I just used a pre-built theme - because if I didn't do that then I would never get time to actually write any blog posts as my own site takes a very low priority for coding time!
Saying that I do like this theme and think the dev did a good job. I have removed that overflow hidden on the body - thanks for the suggestion - so let's hope it's readable now
Yes, and for the people that don't seem to mind that approach, please go ahead and try it out. Personally, I can't imagine setting up the phone on my bed every night or under my pillow. We really think our charging dock with included motion sensor that is non-intrusive and requires no nightly setup is a far superior solution.
WebGL is not a poor-man's subset of OpenGL, its the same subset that is supported by most mobile devices (OpenGL ES2.0). What are you missing? Quads? 3D textures? NURBS?
And yes, we know that JS is interpreted and that it's no use for building anything more than a clock on your webpage, right?
>> WebGL is not a poor-man's subset of OpenGL, its the same subset that is supported by most mobile devices (OpenGL ES2.0).
WebGL is just that, a poor-man's subset of OpenGL. As is OpenGL ES 2, which is a standard that's deprecating very fast as mobile GPU's pack more and more kick-ass.
OpenGL ES standardization efforts are badly left behind the development, as graphics vendors are adding more and more extensions to GLES in their implementations. These extensions tend to be a little stripped down versions of desktop GL features and the worst thing is that they're not quite compatible with desktop GL or even similar extensions form other vendors. Next version of GLES (codename "Halti") has to be standardized pretty fast or it will be out of date by the time it comes out.
If you want to write high quality 3d games or graphics using GLES2, you will have to use vendor specific extensions and write code specifically for the devices you intend to ship on. If you're doing something very basic, you may get away with using only the features in GLES2, but you'll still have to consider how to match the performance to the wide array of GLES2 conformant devices out there. It also helps if you're a part of a major graphics vendor's developer partnership program, like it or not.
WebGL's standardization cycle probably even slower. It took a while for the spec to reach maturity and major browsers implementing it. AFAIK, there's no extension mechanism to gain access to not-yet-standardized features. When the next version of OpenGL ES comes out, how long will it take for it's new features to come available to WebGL? Is the WebGL API even designed for extendability? Who are the industry players willing to contribute their engineering efforts to building WebGL specs and implementations?
Could you write (graphically) Battlefield 3 in WebGL, assuming you'd be able to compile it to run efficiently?
As for your second question, JS is very useful, I love JS, I write 90% of my code in JS. But we're talking sophisticated 3d apps here, not whether it's useful at all.
JS is not very pleasant to code with, so writing an actual game logic could be a bit painful, but so is development for PS3 and it's done somehow. It's not a question of performance, rather about workflow and structures provided by language.
JS has gotchas and some really bad parts, but if you know the language well and know what you're doing, I think it's quite pleasant actually for many problems. Have you done much programming with JS, and if so, what was so unpleasant about it?
Though, I think I've heard pretty much all the complaints against JavaScript, many of which are addressed by using something like CoffeeScript.
I'm using Google Closure to get rid of the bad parts, but still it's not very good. I did some testing with game AI, graphics and so on - JS is far from perfect for such things. Maybe it's a lack of tools, maybe of some features I was used to in C++ or maybe it's that all the books and tutorials are targeted for C++.
It doesn't really matter, browser games are the future and no matter how complicated it's going to be, somebody will be good enough to write them. We already passed "demo era" and some games are really good, like https://chrome.google.com/webstore/detail/bhoaojooagiaaiidln...
The video does not show that anything is being logged or sent through the network.
All it shows is that a phone monitoring agent is informed about events that might be important while debugging - receiveing text, making calls, opening websites, pressing buttons. And that its hard to kill this agent without rooting the device.
What is important is:
1. Is the data logged on the device? (I guess that should be easy on a rooted device),
2. Is there any data sent even if the 'htc quality agent' is not activated? (route it through a linux box, tcpdump)
3. Is the data really anonymized if the 'htc quality agent' is enabled?
"There's no evidence that this crack pipe was used to consume crack cocaine"
The entire purpose of the application is ostensibly to send user activity to a corporation called Carrier IQ. I think the burden of proof is on the application whose purpose is to send user activity to Carrier IQ as to whether or not collected user activity including keystrokes is being sent to Carrier IQ. The fact that the software is able to gain keystroke events and SMS communications at all is a security breach.
I'm sure the problem of determining what confidential information is leaving the device is being worked on right now.
