Categories
Uncategorized

Case study: Saving a leading U.S. law firm over half a million dollars a year

legal books

Creative Commons image by Thomas Eagle. Click the photo to see the source.

A preeminent U.S. law firm with over 1,000 employees and an inventory of over 2,000 mobile devices was facing a number of costly problems:

  • Hundreds of zero-use devices that were still being paid for
  • Unchecked fees arising from overages
  • Mixing of personal and business mobile expenses leading to accounting woes
  • Skyrocketing mobile costs that weren’t being measured or managed

The firm needed to bring their wireless devices and spending under control, and did so with GSG’s help. Using GSGCloud, we were able to perform an audit of their mobile assets, services, and costs, and set into motion a plan to bring them under control.

download pdf

Download our case study [1.1MB PDF] to find out how we brought them an annualized savings of $511,000 and complete visibility into their wireless spending and allocation of costs.

this article also appears in the GSG blog

Categories
Swift Kick

You can use Swift’s “private” access modifier to limit the reach of overrides and extensions, but not monkeypatches

evil monkey pointing at swift code

What happens when you mark operator overload definitions as private?

swift kickWhile I was translating the code in the RayWenderlich.com article Sprite Kit Tutorial for Beginners from its original Objective-C to Swift, I got to the point where he provides some routines to do vector math on CGPoints. These are “standalone” utility functions and aren’t methods inside any class.

The first three functions are for vector arithmetic:

  • Adding two vectors together: (x1, y1) + (x2, y2) = (x1 + x2, y1 + y2)
  • Subtracting on vector from another: (x1, y1) – (x2, y2) = (x1 – x2, y1 – y2)
  • Multiplying a vector by a scalar: (x, y) * k = (k * x, k * y)

Here’s his original code, written in Objective-C:

// Objective-C

static inline CGPoint rwAdd(CGPoint a, CGPoint b) {
    return CGPointMake(a.x + b.x, a.y + b.y);
}
 
static inline CGPoint rwSub(CGPoint a, CGPoint b) {
    return CGPointMake(a.x - b.x, a.y - b.y);
}

static inline CGPoint rwMult(CGPoint a, float b) {
    return CGPointMake(a.x * b, a.y * b);
}

I’ve always found methods like add(firstThing, secondThing) a little clunky-looking; I’d much rather write it as firstThing + secondThing. Since Swift supports operator overloading (Objective-C doesn’t), I decided to implemented the rwAdd(), rwSub(), and rwMult() functions as overloads of the +, -, and * operators. Here’s my equivalent Swift code:

// Swift

// Vector addition
private func + (left: CGPoint, right: CGPoint) -> CGPoint {
  return CGPoint(x: left.x + right.x, y: left.y + right.y)
}

// Vector subtraction
private func - (left: CGPoint, right: CGPoint) -> CGPoint {
  return CGPoint(x: left.x - right.x, y: left.y - right.y)
}

// Vector * scalar
private func * (point: CGPoint, factor: CGFloat) -> CGPoint {
  return CGPoint(x: point.x * factor, y:point.y * factor)
}

Note that I added a private access modifier to each of the functions above. As I pointed out in my last Swift article, Swift’s access modifiers are based on files and modules, not the class hierarchy. In Swift, any entity marked private is visible and accessible within its own file, and invisible and inaccessible from outside its own file. I wanted to see what would happen to operator overloads.

Here’s what I found:

Operator overloads marked private are available within the file where they’re defined, and are not available outside that file. Outside the file where the private operator overloads were defined, any attempt to use them results in an error.

A little testing confirmed that I could add and subtract CGPoints and multiply them by scalars using the + operation from inside the same file, but couldn’t do so from inside in other files.

What happens when you mark extensions as private?

The next couple of functions that were in Sprite Kit Tutorial for Beginners were for getting and normalizing the length of a vector. Here’s the original Objective-C code:

// Objective-C

static inline float rwLength(CGPoint a) {
    return sqrtf(a.x * a.x + a.y * a.y);
}
 
// Makes a vector have a length of 1
static inline CGPoint rwNormalize(CGPoint a) {
    float length = rwLength(a);
    return CGPointMake(a.x / length, a.y / length);
}

Swift supports the addition of functionality to types by means of extensions. I thought that implementing these functions as computed properties of CGPoint in an extension would make for more elegant code — I’d rather write vector.length and vector.normalized than rwLength(vector) and rwNormalize(vector). Here’s what I wrote:

// Swift

private extension CGPoint {
  // Get the length (a.k.a. magnitude) of the vector
  var length: CGFloat { return sqrt(self.x * self.x + self.y * self.y) }
  
  // Normalize the vector (preserve its direction, but change its magnitude to 1)
  var normalized: CGPoint { return CGPoint(x: self.x / self.length, y: self.y / self.length) }
}

Note that I marked the entire extension as private. How would that affect their visibility inside and outside the file where the extension was defined?

The members of extensions marked private are available within the file where they’re defined, and are not available outside that file. Outside the file where the private extension members were defined, any attempt to use them results in an error, and auto-complete wouldn’t even list them.

Once again, testing confirmed that I could normalize and get the length of vectors represented by CGPoints from inside the same file, but couldn’t do so from inside in other files.

What happens when you mark “monkeypatches” as private?

Marking overrides and extensions as private led me to wonder what would happen if I marked a “monkeypatch” as private.

Monkeypatching is a term that’s used in the Python and Ruby developer communities, and it means dynamically replacing an existing class method with one of your own. It’s takes some effort to do in Objective-C (thanks to Joe Smith for the heads-up!), but it’s quite simple to do in Swift — and not just to methods, but properties as well. Here’s a quick example, in which I redefine the String class property utf16Count, which returns the number of UTF-16 characters in a string (it maps to NSString‘s length method):

extension String {
  var utf16Count: Int { return 5 }
}

With this extension, I’ve monkeypatched utf16Count so that it always returns 5, no matter what the number of UTF-16 characters in the string is.

Monkeypatching is powerful, and it’s sometimes useful, but as smarter people than I have pointed out, it can create more problems than it solves. As Jeff Atwood asked in Coding Horror, “Can you imagine debugging code where the String class had subtly different behaviors from the Stringyou’ve learned to use?”

That’s what got me thinking: what if private could be used to limit the scope of a monkeypatch, to limit the applicability of my warped verstion of utf16Count to a single file? Is such a thing possible? To answer these questions, I created this extension to String in one file:

// File: ViewController.swift

private extension String {
  var utf16Count: Int { return 5 }  // already defined in String
  var someNumber: Int { return 10 } // a new addition to String
}

This extension provides two things:

  • A monkeypatch for String‘s already-existent utf16Count property so that it always returns the value 5
  • A new property for String called someNumber, which always returns the value 10

In the same file where I defined my extension to String, I wrote this code:

// File: ViewController.swift

let testString = "This is a test"
println("UTF-16 count inside: \(testString.utf16Count)")
    
doOutsideCount()

And in another file, I defined the doOutsideCount method:

// File: SomeOtherFile.swift

func doOutsideCount() {
  let testString = "This is a test"
  println("UTF-16 count outside: \(testString.utf16Count)")
}

If making the extension private limited my redefinition of utf16Count to the file where I redefined it, the output of doOutsideCount() would be “UTF-16 count outside: 14”, since there are 14 UTF-16 characters in testString. I noticed that while typing in the code in this file, utf16Count was available to me in auto-complete.

Here’s the output that appeared on the console when I ran the app:

UTF-16 count inside: 5
UTF-16 count outside: 5

It appears that monkeypatching (redefining an existing member) in an extension marked private does not limit the monkeypatch to the file where the monkeypatch was defined. You can’t use private to limit the scope of a monkeypatch to a single file.

I changed the code in both files to try calling on someNumber, a method that didn’t already exist in String:

// File: ViewController.swift

func doOutsideCount() {
  let testString = "This is a test"
  println("someNumber inside: \(testString.someNumber)")
}

// File: SomeOtherFile.swift

func doOutsideCount() {
  let testString = "This is a test"
  println("someNumber inside: \(testString.someNumber)")
}

This wouldn’t even compile. Calling on the someNumber property of String outside of the file where I defined the private extension raises an error: 'String' does not have a member named 'SomeNumber'.

My conclusion from this little bit of experimenting is also this article’s title:

You can use Swift’s private access modifier to limit the reach of overrides and extensions, but not monkeypatches.

Categories
Uncategorized

Americans can unlock their phones again…legally!

it's legal again

It’s official: President Obama will sign the Unlocking Consumer Choice and Wireless Competition Act, which brings back an important exemption to the Digital Millennium Copyright Act that lets customers and authorized third parties modify a phone’s firmware and thus removing restrictions that most carriers put on their phones. The White House blog explains how this change was brought about in greater detail, but for those of you who’d rather not get into all the legal stuff, here’s the practical upshot:

You can now unlock your phone (or hire a service to do it for you) so that you can switch carriers, all without getting fined or sued.

Have a happy Friday!

this article also appears in the GSG blog

Categories
Uncategorized

Mobile hardware news roundup: What’s in Amazon’s Fire Phone, here come the 64-bit mobile devices, and faster RAM is on the way

Amazon’s Fire Phone: Made up of $205 of parts and so-so reviews

fire phone - 205 in parts

In their latest “teardown”, research firm took apart an Amazon Fire Phone, looked at its components and tallied up their total cost to be $205. As of this writing, it sells for $649 without contract on Amazon’s site. This is more than the cost of parts in the current iPhones (according to IHS, the parts for an iPhone 5C cost $173, and for an iPhone 5S, the cost is “at least $199”), and less than the cost of parts for a Samsung Galaxy S5 (which IHS says is about $256).

Upon examining the Fire Phone’s components, IHS analyst Andrew Rassweiler says that it’s “a pretty standard mid-range phone from a hardware perspective”, with the notable exception of its “Dynamic Perspective” feature, which is enabled by additional sensors in each corner. Dynamic Perspective uses the sensors to determine the phone’s orientation in relation to the user’s head combined with some imaging tricks to make pictures on the screen look almost three-dimensional:

Among the parts found in the Fire Phone were a member of the Qualcomm Snapdragon chip family as its main processor, which also power Samsung’s Galaxy S5, Nokia’s Lumia 1520, and ZTE’s Grand S II, and a 720p display, which at $27, is considerably cheaper than the display in the iPhone 5S ($43) or the Galaxy S5’s ($63).

If you’re more concerned about the reviews of the Fire Phone in action rather than its innards:

Expect to see more 64-bit phones on the market next year

qualcomm parts

Right now, Apple has the only devices with 64-bit processors: the iPhone 5S and the 2013 family of iPads, and that development is said to have created a lot of concern among the competition. In an interview with Dan Lyons, an unnamed Qualcomm employee is quoted as saying:

“The 64-bit Apple chip hit us in the gut. Not just us but everyone, really. We were slack-jawed, and stunned, and unprepared. It’s not that big a performance difference right now, since most current software won’t benefit. But in ‘Spinal Tap’ terms it’s like, 32 more, and now everyone wants it.”

When we talk about “32-bit” and “64-bit” processors, we’re talking about the number of bits — that is, BInary digITs — that the processor can use to access memory. A 32-bit processor can access 232 memory locations, which corresponds to 4 gigabytes. There’s no point to putting more than 4GB of RAM in a 32-bit device — it wouldn’t be able to use access any more than the first 4 gigs. That’s the 64-bit advantage: A 64-bit processor can access 264 memory locations, or 16 exabytes, where an exabyte is a billion gigabytes. Being able to access more memory means than programs can be larger (and more feature-filled), and can perform even more complex tasks. Keep in mind that we’re talking about active memory, or RAM, which the CPU uses to perform its tasks, and not the storage or “hard drive” space.

That situation is expected to change next year with the release of the Qualcomm Snapdragon 810 series of chips, their first 64-bit mobile processors. Aimed at high-end “flagship” phones, you should start seeing them appear in top-of-the-line 2015 smartphones and tablets, with the usual “trickle-down” effects appearing in less expensive devices over time.

Faster RAM for mobile devices on the way

cheetah

Not only will mobile devices be able to access more memory soon, they’ll also be able to do so much faster. It’s expected that LP-DDR4 technology, a low-power version of the DDR4 RAM already seen in today’s better desktop and laptop computers, will go mainstream in 2016, which is two years earlier than projected. Samsung estimates that the new memory technology will be 50% faster and 40% more power-efficient than the current LP-DDR3 technology used in to smartphones, and will offer data transfer speeds of 17 gigabytes per second — 34 gigabytes a second for 64-bit devices. As one might expect, Qualcomm have already announced support for LP-DDR4 technology in the Snapdragon 810 chipset.

this article also appears in the GSG blog

Categories
Uncategorized

Mobile news roundup for the “road warriors”: Charge quickly, find hotels with good wifi, and use your phone as your room key at Hilton hotels

Charge your smartphone in 15 minutes with the Ultrapak

15 minutes to full charge

Sometimes it happens: you’ve been making heavy use of your phone or tablet, and now it’s low on power. Sometimes, you get lucky and have both the time and nearby outlet to get enough power to carry on. For those other times when you’re short on both time and a convenient power source, you might want to have an Ultrapak handy. Farhad Manjoo reports on his experience with the Ultrapak in a New York Times piece, where he calls it “a lifesaver” and closes with “If there’s a better way to power up quickly, I haven’t seen it.”

Find out which hotels have the best wifi at HotelWifiTest.com

hotel wifi rating site

There’ve been many times where I’ve had to get work done from my hotel room or in the lobby or cafe and found myself packing up for the nearest Starbucks after getting frustrated with the wifi speed. While there are many sites that rate hotels on many dimensions, wifi connectivity hasn’t been one of those criteria. Luckily for us, there’s HotelWifiTest, a site that provides speed test results for various hotels around the world. The database is a bit small as of this writing: it covers 160 hotels in New York, 42 in San Francisco, and 52 in London, England for starters, but since it lets users run tests and submit results from their hotels, it’ll become more useful as it becomes more popular. (You can also use their speed test to check the wifi speed anywhere, including your home and office.)

Hilton hotels switching to smartphone-enabled locks

your phone is your key

The Wall Street Journal may have hidden this story behind their paywall, but other sites such as Gizmodo are reporting this news: the Hilton Hotel chain is upgrading its rooms and equipping them with smartphone-enabled door locks. Not only will you be able to use your smartphone as your room key, you’ll be able to bypass the whole front desk check-in dance entirely. They expect to have the majority of their hotels upgraded by 2016.

this article also appears in the GSG blog

Categories
Uncategorized

BYOD news roundup: Millennials are the biggest rulebreakers, nearly 80% of orgs lack BYOD policies, mobile is the new desktop, and some want their BlackBerry back

Millennials are BYOD’s biggest rulebreakers, but there’s a method to their misdemeanors

Millennials — the generation born between the early 1980s and early 200s — already have a bad enough reputation in the workplace:

It turns out that they’re also the employees who break companies’ BYOD rules most often, and they’re doing it to work more effectively. A survey conducted by Trackvia, a company that makes a platform to let non-programmers create their own mobile business apps, reveals the following observations from 1,000 respondents interviewed in June:

  • 60% of the Millennial respondents “aren’t concerned about corporate security when they use personal apps instead of corporate-approved apps” because those apps aren’t up to the job. They’d much rather use apps that they believe are better.
  • 69% of the Millennial respondents say they never work in conjunction with IT department when selecting new business apps.35 percent of Millennials use their own apps because corporate-approved apps cannot be used across different devices.
  • 35% of the Millennial respondents say they use their own apps because corporate-approved apps can’t be used across different devices.
  • While nearly 70% of respondents from the Baby Boomer generation (people born between 1946 and 1964) said they never use “outside” apps to support their work, only 31% of the Millennials said the same. In other words, the percentage of Baby Boomers who didn’t use outside apps is about equal to the percentage of Millennials who did use them.

For more from the survey, see Trackvia’s report, titled Rebels With a Cause, and the infographic below:

trackvia - rebels with a cause

Vectra Networks/LinkedIn Information Security Community study: Nearly four-fifths of organizations lack a BYOD policy

Gold Key Opening a Gold Lock (with Clipping Path)

In another BYOD study — this one conducted jointly by security platform company Vectra Networks and LinkedIn’s Information Security Communty group — over 1,100 IT professionals were interviewed about BYOD in their workplace. Here are some of the statistics:

  • 79% have “not fully implemented” BYOD policies, processes, and infrastructure”.
  • 24% did not even have a mobile device policy.
  • When it came to protecting company data, respondents were most concerned about these:
    • Business data (74%)
    • Customer/employee data (69%)
    • Documents (66%)
  • The most common security measures for mobile devices used at respondents’ companies were:
    • Passcode protection (67%)
    • Remote wiping of data (52%)
    • MDM (43%)
    • Encryption (43%)
    • Endpoint security tools (39%)
    • Network access controls (38%)

For more from the study, see Vectra Networks’ 2014 BYOD and Mobile Security Report.

Mobile is the new desktop

With just about as many mobile subscriptions as there are people worldwide, it shouldn’t come as a surprise that people are adopting mobile devices for every aspect of their lives, including work. The problem is that with increased use of mobile devices, especially personal ones, come increased security risks. Many organizations have been slow or resistant in adopting mobile technologies, but as InformationWeek’s Dark Reading blog puts it, “it’s happening, whether IT or security teams believe it or not”. 

The infographic below was created by mobile security vendor BlueBox and shows mobile device use at work, and the gap in concerns about mobile that separates employees from IT:

mobile is the new desktop

The Apple/IBM partnership may help alleviate enterprise BYOD pain

iphone and blackberry

The unexpected is happening at a “well-known investment firm” in New York City: nearly 60% of them are encountering enough frustration with their BYOD devices that they want to return to two phones — one for personal use, one for work — and are saying “I want my BlackBerry back”. It turns out that the MDM has been draining their devices’ batteries and interfering with their work (one example: one MDM app didn’t let them send email from within a Salesforce app or open a PDF with GoodReader), and their BYOD policies are skewed too heavily in favor of the company’s rights over employees’ privacy.

AppleInsider suggests that the recently-announced enterprise mobility partnership between Apple and IBM may solve these problems, with its promised IBM-developed “device management native to iOS” and a new “end-to-end procurement and lifecycle management services allow employees to manage their own mobile devices” may alleviate these problems. They’re not available yet, and if you’re thinking of adopting a BYOD policy at your organization, you have to consider the trade-offs that exist in the here and now.

Special thanks to Phil Caruso, Director, Channel Programs at GSG, for helping with this article!

this article also appears in the GSG blog

Categories
Uncategorized

Learn how to build Shopify apps with “Shopify Application Development”, a book technically reviewed by Yours Truly

shopify application development

Michael Larkin has been helping people build online shops with Shopify for years in all sorts of ways. He’s helped people set up shops, he’s taken stock Shopify stores and hot-rodded them with all sorts of customizations, and he co-authored one of the first Shopify apps, FetchApp, which makes it possible to sell downloadable digital goods with Shopify. He recently wrote Packt Publishing’s Shopify Application Development, a quick read that’ll walk you through the process of building Shopify apps with Ruby on Rails, following good practices like test-driven design while you’re doing it. Among the things you’ll do by following the book’s exercises are:

  • Learn how to configure your Rails development environment for building Shopify apps, testing them with RSpec and FactoryGirl, and deploying them to Heroku
  • Connect an app to Shopify, and work with Shopify’s API and Webhooks
  • Build both private apps for use by a single store, and public apps, which any number of stores can use
  • Publish your app to the Shopify store so that you can sell it to vendors and make some money for your efforts

It has a number of technical reviewers, including one you might have heard of:

joey devilla tech reviewer

The book’s a mere 109 pages and should be a good starting-off point for your Shopify app development. You can order the ebook version directly from Packt for under $20; the paper book version (which comes with the ebook for free is about $30. It’s also available on Amazon, with the Kindle version priced at just under $10, and the paper book version under $30.