Search Results

Search found 7 results on 1 pages for 'mbrit'.

Page 1/1 | 1 

• I'm crowdsourcing "action shots" of Surface OR iPad for a ZDNet piece

  - by mbrit

  What I'm looking for here is people using their tablets in normal, everyday settings.Such as this one from Microsoft evangelist Martin Beeby using his Surface on a train:https://twitter.com/thebeebs/status/264259464201388032/photo/1Please send your pictures to [email protected]. You will retain copyright of the images, but by sending them to me you grant me permission to use them on ZDNet and associated properties.

  Read the article

• Say goodbye to System.Reflection.Emit (any dynamic proxy generation) in WinRT

  - by mbrit

  tl;dr - Forget any form of dynamic code emitting in Metro-style. It's not going to happen.Over the past week or so I've been trying to get Moq (the popular open source TDD mocking framework) to work on WinRT. Irritatingly, the day before Release Preview was released it was actually working on Consumer Preview. However in Release Preview (RP) the System.Reflection.Emit namespace is gone. Forget any form of dynamic code generation and/or MSIL injection.This kills off any project based on the popular Castle Project Dynamic Proxy component, of which Moq is one example. You can at this point in time not perform any form of mocking using dynamic injection in your Metro-style unit testing endeavours.So let me take you through my journey on this, so that other's don't have to...The headline fact is that you cannot load any assembly that you create at runtime. WinRT supports one Assembly.Load method, and that takes the name of an assembly. That has to be placed within the deployment folder of your app. You cannot give it a filename, or stream. The methods are there, but private. Try to invoke them using Reflection and you'll be met with a caspol exception.You can, in theory, use Rotor to replace SRE. It's all there, but again, you can't load anything you create.You can't write to your deployment folder from within your Metro-style app. But, can you use another service on the machine to move a file that you create into the deployment folder and load it? Not really.The networking stack in Metro-style is intentionally "damaged" to prevent socket communication from Metro-style to any end-point on the local machine. (It just times out.) This militates against an approach where your Metro-style app can signal a properly installed service on the machine to create proxies on its behalf. If you wanted to do this, you'd have to route the calls through a C&C server somewhere. The reason why Microsoft has done this is obvious - taking out SRE know means they don't have to do it in an emergency later. The collateral damage in removing SRE is that you can't do mocking in test mode, but you also can't do any form of injection in production mode. There are plenty of reasons why enterprise apps might want to do this last point particularly. At CP, the assumption was that their inspection tools would prevent SRE being used as a malware vector - it now seems they are less confident about that. (For clarity, the risk here is in allowing a nefarious program to download instructions from a C&C server and make up executable code on the fly to run, getting around the marketplace restrictions.)So, two things:- System.Reflection.Emit is gone in Metro-style/WinRT. Get over it - dynamic, on-the-fly code generation is not going to to happen.- I've more or less got a version of Moq working in Metro-style. This is based on the idea of "baking" the dynamic proxies before you use them. You can find more information here: https://github.com/mbrit/moqrt

  Read the article

• FileOpenPicker/FileSavePicker doesn't allow *.* wildcard file associations

  - by mbrit

  On Twitter, Matthias Jauernig commented that the FileOpenPicker and FileSavePicker doesn't allow *.* wildcard file associations. I was relaxed about this and wrote back that it was related to sandboxing implying it was a "good thing", however as Matthias commented back, perhaps it's not.In Metro-style the sandboxing works that if something gives you a file (e.g. the picker, or a share operation), you can access it regardless of where on the system. If you find the file yourself, you have to declare the type.The reason why I think it's related to sandboxing is because if you work with files programmatically you have to be explicit about the file types. This is to stop malware that you think is only interested in - say .PDF files, scanning and uploading any .EML files that it can find on the machine. It follows then on the pickers that restriction would continue. It allow's the retail store team to validate that an app is likely to behave itself. If it's an app that works with images, locking down the picker so that it can only access image file types makes sense.However Matthias mentioned that he has an app that should allow files of any arbitrary file. That fits more into the "if the user selects it, it must be OK" camp than the "programmatic scanning" camp. So now I'm left wondering why the picker doesn't allow any type to be selected.I think then maybe the decision comes down to simplicity. A lot of the decisions in Metro-style design relate to ideas about "zero intimidation". Allow the user to select any file is too much like Old Windows, and not enough like Reimagined Windows. What happens in Matthias's app if the user selects Explorer.exe as the file he or she wants to work with? I guess it's fine if you expect your user to know what they're doing (Old Windows), but not so fine if you're expecting a three year old to work with it (Reimagined Windows).

  Read the article

• Virtualising Windows 8 on OS X with VMware Fusion above the 8GB limit

  - by mbrit

  tl;dr - don't.VMware Fusion has an 8GB limit, so on my 16GB MacBook Pro (which is an old one with a 16GB memory upgrade), I wanted to use more than 8GB. You can fudge it my editing the .vmx file and changing the memsize value to whatever you want.However it turns out that if you do this the performance on the whole machine turns into a big. It beachballs all over the place, both in VMware and without. Constant hanging of VMware, fan running hot the whole time, etc.This is just an apocryphal view, but having spent a week and a half with it unusable and me thinking I was going to have to go back to Win7, turn it down back to using 8GB exactly seems to be working much more stably.

  Read the article

• RIM's current BB7 developer toolset is a joke

  - by mbrit

  tl;dr - RIM's current developer toolset is not fit for purpose.Background to this is that I'm currently working on a PhoneGap/Cordova project for a client that has to run on BlackBerry. The tooling is so ridiculous to use that even though I had a gentle dig at them in a Guardian piece it's worth having a more full-on attack.At the moment, RIM's pitch is that apps are built for the current BBOS7 devices using WebWorks. This is an HTML-based toolset. Essentially a browser is spun up in a native app container and your app is powered by JavaScript. Specific JavaScript libraries exist that thunk down to native capabilities no the device. I happen to use PhoneCap/Cordova in combination with this.The tooling is non-existent. I'm using TextMate, Ant, and Terminal to develop the app. There's no "console.log" output, and no debugging. The only way to instrument the app is to put "alert" calls in your code.Apart from the fact that that's *not* fine in 2012, how about this… every time you deploy a new app to the device, the device has to reboot. This process takes six minutes on a relatively modern BlackBerry device. How about this as well - in order to get a file into the package it has to be signed. My small app over here has 100 different files (75 or so generated). Signing doesn't happen locally, it happens on RIM's servers in Waterloo. Thus whenever you deploy the app you have this utility have to call RIM's servers 100 times. More to the point, sometimes during the day these servers have "micro-downtime" moments where they're unreachable for five or ten minutes, normally two or three times a day. Oh yes, you'll also get an email sent to you per signing on success or failure. 100 inbound emails, per deployment.(I started this post at the beginning of one of these cycles, by the way. That's how long it takes to build and deploy *once*. By the way, the change I made didn't work.)To clarify:* Change the script,* Build it using Ant,* Ant will spin up a Java app that talks to RIM's servers to sign it.* Receive 100 emails, assuming the server is up.* App deployed - takes about 30 seconds.* BlackBerry device restarts - takes about six minutes.* Find and open the app. Go through security prompts.* Test the app, with no "console.log" output and no debugger."Why not use the simulator?" I hear you ask. Well, apart from the fact that the simulator refused to reach any network service over HTTPS that I happen to own? (Some people suggest changing DNS settings for this known issue.) Admittedly, the simulator does show you console.log, but you still have the "six minute" restart issue on the simulator.Developers will understand this problem. Breaking concentration for six-plus minutes every time you want to deploy an app turns developing into a nightmare. Combining that with no worthy debugging tools turns the toolset into a joke.

  Read the article

• Windows 8 keyboard shortcuts when virtualising OS X

  - by mbrit

  Seriously, I have no idea why this took me so long to actually sort out.So in Windows 8 you have new keyboard shortcuts for accessing search (Win+Q), charms (Win+C), settings (Win+I), etc. Problem is that some of those collide with standard OS X mapping - for example Win+Q will close down VMware, Win+C will issue copy, etc.You can add additional mappings into VMware. Use the Preferences panel to do that. Here you can see that I've mapped Win+Shift+C to Win+C. (OK, that assumes you use a Windows keyboard with a Mac, like I do. If you use a Mac keyboard, you're mapping Apple+Shift+C to Win+C.)

  Read the article

• Detecting right-click on XAML GridView control item

  - by mbrit

  Leaving aside why you would ever want to do this in a touch-centric world, here's how you tell if the right-mouse button has been clicked on a GridView in XAML/WinRT/Metro-style. You have to retrieve a point relative to the UI element you're in, and then query its properties. void itemGridView_PointerPressed(object sender, PointerRoutedEventArgs e) { if (e.GetCurrentPoint(this).Properties.IsRightButtonPressed) { this.BottomAppBar.IsOpen = true; } } (The reason why you might want to do this can be explained by looking at any of the built-in Win8 apps. You can right-click any of the items on any list to bring up a context-sensitive AppBar.)

  Read the article

1