Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/1&page=5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Why Contribute To Open Source?

Making the Complex Simple - John Sonmez - Mon, 03/14/2016 - 13:00

The Open Source Software movement encompasses all kinds of solutions for all kinds of problems, some of which programmers themselves benefit from, others of which serve as hobby projects or creative tools that programmers with non-programming interests contribute to. The most obvious Open Source software platform anyone could probably think of is the ecosystem for […]

The post Why Contribute To Open Source? appeared first on Simple Programmer.

Categories: Programming

First Preview of Android N: Developer APIs & Tools

Android Developers Blog - Sat, 03/12/2016 - 03:26

Posted by Dave Burke, VP of Engineering

Today we’re happy to announce a Developer Preview of the N release of Android! We’re doing something a little different this year by releasing the preview early… really early. By releasing a “work in progress” build earlier in development, we have more time to incorporate developer feedback. Also, the earlier preview allows us to hand off the final N release to device makers this summer, so they can get their hands on the latest version of Android earlier than ever. We’re looking forward to getting your feedback as you get your apps ready for N.

Here are a few APIs and features we want to highlight which are available as a part of the Android N Developer Preview today, with more to come as we continue developing the release:

Multi-window - A new manifest attribute called android:resizableActivity is available for apps targeting N and beyond. If this attribute is set to true, your activity can be launched in split-screen modes on phones and tablets. You can also specify your activity's minimum allowable dimensions, preventing users from making the activity window smaller than that size. Lifecycle changes for multi-window are similar to switching from landscape to portrait mode: your activity can handle the configuration change itself, or it can allow the system to stop the activity and recreate it with the new dimensions. In addition, activities can also go into picture-in-picture mode on devices like TVs, and is a great feature for apps that play video; be sure to set android:supportsPictureInPicture to true to take advantage of this.

Direct reply notifications: The RemoteInput notification API, which was originally added for Android Wear, now works in N for phones and tablets. Using the RemoteInput API enables users to reply to incoming message notifications quickly and conveniently, without leaving the notification shade. Learn more here.

Bundled notifications - With N, you can use the Notification.Builder.setGroup() method to group notifications from the same app together - for example individual messages from a messaging app. Grouped notifications can be expanded into individual notifications by using a two-finger gesture or tapping the new expansion button. Learn more here.

Efficiency - We launched Doze in Marshmallow to save battery when your device is stationary. In N, Doze additionally saves battery whenever the screen turns off. If you’ve already adapted your app for Doze, e.g. by using the GCM high priority message for urgent notifications, then you’re set; if not, here’s how to get started. Also, we’re continuing to invest in Project Svelte, an effort to reduce the memory needs of Android so that it can run on a much broader range of devices, in N by making background work more efficient. If you use JobScheduler for background work, you’re already on the right track. If not, N is a good time to make that switch. And to help you out, we’re making JobScheduler even more capable, so now you can use JobScheduler to react to things like changes to content providers.

Improved Java 8 language support - We’re excited to bring Java 8 language features to Android. With Android's Jack compiler, you can now use many popular Java 8 language features, including lambdas and more, on Android versions as far back as Gingerbread. The new features help reduce boilerplate code. For example, lambdas can replace anonymous inner classes when providing event listeners. Some Java 8 language features --like default and static methods, streams, and functional interfaces -- are also now available on N and above. With Jack, we’re looking forward to tracking the Java language more closely while maintaining backward compatibility.

Get started

The N Developer Preview includes an updated SDK with system images for testing on the official Android emulator and on Nexus 6, Nexus 5X, Nexus 6P, Nexus Player, Nexus 9, and Pixel C devices (and to help test out these features on a tablet, developers can get a $150 discount on Pixel C), as well as on General Mobile 4G (Android One) devices.

This initial preview release is for developers only and not intended for daily use or consumer use. We plan to update the N Developer Preview system images often during the Developer Preview program. As we get closer to a final product, we’ll be inviting consumers to try it out as well.

We are also making it easier for you to try out N on your development devices with the new Android Beta Program. Starting today, you can update your Android devices to the developer preview of N and receive ongoing updates via OTA by visiting g.co/androidbeta.

Click here for more details on getting started with the N Developer Preview and let us know what you think -- the sooner we hear from you, the more of your feedback we can integrate.

Categories: Programming

Digital Transformation is Ongoing

Digital Transformation is much broader than a technical play.  It’s a chance to reimagine your customer experience, how your employees work, and how you perform operations.

It’s also a chance to continuously create and capture value in new and innovative ways, and I don’t just mean with DevOps.

Your business isn’t static.  Neither is the world.  Neither is the market.  Neither is Digital Transformation.

Instead, Digital Transformation is a way to continuously evolve how you create and capture value in a mobile-first, cloud-first world.

In Digital Transformation Dr. Mark Baker shares how “digital” is more than just bits and bytes and there is always more Digital Transformation that can be done.

Digital Transformation is Bound by Business Decisions, Not Technical Ones

Your Digital Transformation should not be bounded by technical decisions.  Your Digital Business Transformation approach should be driven by your business decisions and your business design.  What matters is that the landscape is digital and that you have to design for new customer experiences, new ways of working, and new ways of performing operations in a mobile-first, cloud-first world.

Via Digital Transformation:

“Today, when we talk of digital transformation we mean restructuring an organization to use any and all information and network-based technologies that increase its competitiveness, in a way that, over a period of time, excludes and out-competes un-transformed organizations.  Of course, in a literal sense, when we walk literally about digital we mean something like expressing data as series of the digits 0 and 1 or using or storing data or information in the form of digital signals: digital TV, a digital recording or a digital computer system.

However, if we think about it that way the whole scope of our understanding and what we are thinking of achieving is quite limited and fairly technical.

In the bigger sense of digital we mean a road map that includes the full process of making a business or service so that every part is freely accessible at every level with bounds set by explicit management models, not by physical constraints.  Ultimately it means that all decisions become business or usage decisions, not technical ones.”

Example of First Generation Digital Transformation

There are always some basic things you can do to get in the game of Digital Transformation.  But that is just the start.  Baker shares an example using a library and how they performed their Digital Transformation.

Via Digital Transformation:

“It might be useful to give a simple example where, whose general principles apply to all digital projects.  The Bodleian Libraries are a collection of approximately 40 libraries that serve the University of Oxford in England.  One of the largest and most important libraries in the world, they hold 11 million printed items, 153 miles (246 kilometers) of shelving, including 3,224 bays with 95,000 shelf levels, and 600 map cabinets to hold 1.2 million maps and other items.

During the first generation of transformation I talked to senior librarians at the Bodleian, and the digital library projects that I was told of turned texts into bitmaps.  Information was still effectively siloed and not electronically searchable within books, but the advantage of digital transformation at that stage was that the physical master copies were protected and copies could be sent with manually controlled access over electronic network to authorized users anywhere in the world.”

Example of Second Generation Digital Transformation

Once you go digital, more opportunities open up for further transformation.  Baker continues the example of a library that undergoes Digital Transformation.

Via Digital Transformation:

“Later more advanced approaches, like Project Guttenberg, digitized the text into ASCII format so that catalogs of books were both digital and searchable as were the individual books.  Beyond that, projects like Google Books Library Project allowed the whole contents of all the books to become accessible to a single keyword search that could search all text across volumes.”

There is Always More Digital Transformation That Can Be Done

There is always more you can do and there are many stages to a full Digital Transformation.

Via Digital Transformation:

“Of course, going digital goes beyond digitizing content and a more advanced model would determine accessibility, access and usage rights and payments, not just in the local user community but worldwide.  In a project of that type any user would be able to do keyword searches across all the contents of a particular library and then usage and any payment would be determined for the specific books or documents they wanted access to, appropriate access would be granted and payment (if any) would be collected. If acquisition was performed on the same platform then requests for information, usage statistics, reader feedback and null-searches could be matched to the acquisition of new materials for the library, so as to better serve the users.

Ultimately even search goes further so that improved semantic search tools would allow search by meaning s well as by key words or phrases, as well as predictive analysis of future usage creating a proactive model, rather than a  reactive model where the available content is always out of date.

At each state the instigators might have expressed the view that they had ‘gone digital’ and at each stage there would have been much, much more that could be done.  This is, of course, just one specific instance of digital transformation related to libraries, but shows a simplified example of how there are many stages to a full transformation.”

Digital Transformation is not done when you are “transformed.” 

It’s a journey of continuous evolution.

You Might Also Like

Build Better Business Cases for Digital Initiatives

Business Value Generation is the New Bottleneck

Continuous Value Delivery the Agile Way

Digital Transformation is Business Transformation

Drive Business Transformation by Reimagining Your Customer Experience

Drive Business Transformation by Reimagining Your Operations

Dual-Speed IT Drives Digital Business Transformation

How Leaders are Building Digital Skills

How To Build a Roadmap for Your Digital Transformation

Microsoft Stories of Digital Business Transformation

Categories: Architecture, Programming

App Monetization Insights: How TapBlaze designed their game app for user retention

Google Code Blog - Fri, 03/11/2016 - 20:16

Originally posted by Inside AdMob blog

Posted by Joe Salisbury, Product Specialist, AdMob

This is post 3 of AdMob's 5-part blog series featuring monetization tips straight from successful app developers. If you’re interested in further exploring the question, “what’s the best way to monetize my app?”, check out AdMob's free No-nonsense Guide to App Monetization.

AdMob's guest this week is Anthony Lai, founder of TapBlaze, a popular game app company based in Los Angeles, California. TapBlaze has developed over 15 titles, collectively garnering millions of downloads. Anthony’s been able to grow the company from a one-person show, to a team of 7 full-time developers, designers, and artists. Check out these tips from Anthony.

1. Design your app for retention.
When Anthony first started TapBlaze, he initially focused on building simple, virtual simulation games. An example was his app “Good Pizza, Great Pizza”, which allowed users to virtually make and sell pizza. These early apps were interesting concepts and received a lot of attention but had a difficult time retaining customers. After the novel experience wore off, users had little reason to come back.

For his next game, Anthony wanted to build something that would keep users engaged for months, not days. To do this, he infused 4 elements into his new match 3 puzzle game named Gummy Gush: 1) a compelling story, 2) fun challenges, 3) rewards, and 4) multiple levels that built on each other. This took a lot more time to develop, and his key metric (retention) took a little longer to measure than downloads, but the work payed off.

“When we first launched Gummy Gush there were some players that only played for a few days, but there were others that clearly liked the art, story and puzzles and just kept playing. It was working! That was enough encouragement for us to keep improving these elements into the game. Ultimately this investment lead to much higher revenue, and even to rapid growth. Since launching in March of 2015, we have over 1,000,000 downloads.”
Consider designing your app for retention. Retention is a key metric for successful monetization and nailing retention will lead to a much more long term, sustainable business. To learn more about practically how to retain users, check out this video from Google Developers called “The Zen of Monetization: The Art of Retaining Users”.

2. Understand the amount of polish your app needs to succeed.
Early last year, Anthony’s team was focused on launching Gummy Gush as quickly as possible. Anthony’s a firm believer in swiftly getting product in the hands of users to collect real user feedback, then iterate. His aggressive timeline meant making sacrifices with the polish of the app, but because he had a few artists on the team he was confident that v1 would be “good enough”.

After launch, there was no user feedback on the polish of the game. But, a new engineering hire with a lot of game development experience urged them to invest in perfecting the look and feel of the game – standardizing UI elements, smoothing out all animation, and adding the finishing touches to the art work.

At first, Anthony was skeptical. But, they decided to devote 2 weeks to the initiative and see how it affected their key metrics. The overhaul paid off big time. Within the first week of the update, Gummy Gush saw a 25% in average revenue per user (ARPU).

Depending on the type of app you're building, fierce competition may have raised the bar for the amount of polish that users expect. For Anthony’s niche, a beautifully designed app built trust and increased revenue. If you’re in a highly competitive sector, it's important to assess what the industry’s threshold for aesthetic finish looks like and decide whether an investment in design app is worth making. Check out Google Play’s “Top Charts” to see what the benchmark is for your category.

3. Use analytics to prioritize your team’s next steps.
After launching, user feedback started rolling in. Although a lot of the reviews were helpful, there were also a number of issues that were unclear. He explained,

“We’d receive a lot of positive and negative reviews and emails from users and didn’t know how representative the feedback were of the broader user base. Were the complaints from users who’d complain no matter what? Or were the complaints serious problems that deserved to prioritize?”
What made it tougher was the time already spent on some of the features being criticized. For example, Anthony had invested in building an engaging introduction story that played the first time users opened the app. He even worked with a professional story writer to impart light-hearted humor in the story. His instincts knew that the story made this new app more compelling than his older apps, but did he go too far?

His solution: test solutions with his users. The team built the smallest version of solutions to proposed problems, taking no more than 2 weeks to release. They’d then monitor key metrics to see if the change had a positive affect. For the introduction story, the team quickly built a “skip” button. After releasing it, nearly 60% of users used it, confirming that it was a real problem worth solving more deeply.

For your app, use in-app analytics to test the individual pieces of feedback you get from users and internal hunches your team comes up with. Overdevelopment is more costly only to find out that your assumptions are wrong is much more costly that actual testing and observation. To learn more about observational testing, check out Tomer Sharon’s talk at Google I/O called “Don't Listen to Users, Sample Their Experience!”.

If you found these tips helpful, don’t forget to check out The No-nonsense Guide to App Monetization. Also, stay connected on all things AdMob by following their Twitter and Google+ pages and be sure to connect with TapBlaze on Twitter here.

Categories: Programming

Introducing Chrome Music Lab

Google Code Blog - Fri, 03/11/2016 - 19:04

Posted by Alex Chen, Coder and Designer, Google Creative Lab

This year, for Music in Our Schools Month, we wanted to help make learning about music a bit more accessible to everyone by using technology that’s open to everyone: the web. We built a set of experiments that let anyone explore how music works. It’s called Chrome Music Lab, and you can check it out at g.co/musiclab.

The experiments all use the Web Audio API, an open web standard that lets you create and manipulate sound right in the browser. In Chrome Music Lab, we’re using Web Audio to create interactive drum machines, pianos, synthesizers, and more. A few experiments also let you use the microphone input in Chrome through WebRTC. This lets you use your own voice or real sounds around you as part of the experiment.

The web has always been a space for open collaboration. Many of these experiments use grassroots efforts such as Tone JS, a framework built on top of the Web Audio API that makes it even easier to build interactive music experiences in the browser.

We’re also providing open-source code. So if one of our experiments sparks an idea, check out our repository and start building your own.

Categories: Programming

Coffee with Now on Tap PM Paige Dunn-Rankin

Google Code Blog - Fri, 03/11/2016 - 00:21
Posted by Laurence Moroney, Developer Advocate

Google Now on Tap is a feature for Android phones that lets you get quick information about what you’re doing without leaving your app, simply by holding the Home button. Laurence catches up with Paige Dunn-Rankin a product manager for Now on Tap to discuss this great technology.

It builds upon what Google Now has already done -- but making it much more personal, based on what’s on your screen right now.

She demonstrates a chat session with a friend, where from the context of their conversation, Now on Tap can figure out the landing time for the flight he’s on, the location and reviews of the restaurant they want to attend, and even integrate neatly with calendar to create a calendar event. She also shows me how natural language processing does this -- in the conversation they didn’t talk about a calendar, just about having dinner, but Now on Tap figured out the correct time and date for them. For example, when watching a YouTube video, you can hold the Home button to launch Now on Tap and it will give you related content and events!

Now on Tap works on top of most apps with no changes needed. If you want to make sure that Now on Tap works seamlessly on top of your app, make sure to check out "Optimizing Content for the Assistant" here. To make your app show up in Now on Tap links, use App Indexing.

Categories: Programming

Coffee with Now on Tap PM Paige Dunn-Rankin

Google Code Blog - Fri, 03/11/2016 - 00:21
Posted by Laurence Moroney, Developer Advocate

Google Now on Tap is a feature for Android phones that lets you get quick information about what you’re doing without leaving your app, simply by holding the Home button. Laurence catches up with Paige Dunn-Rankin a product manager for Now on Tap to discuss this great technology.

It builds upon what Google Now has already done -- but making it much more personal, based on what’s on your screen right now.

She demonstrates a chat session with a friend, where from the context of their conversation, Now on Tap can figure out the landing time for the flight he’s on, the location and reviews of the restaurant they want to attend, and even integrate neatly with calendar to create a calendar event. She also shows me how natural language processing does this -- in the conversation they didn’t talk about a calendar, just about having dinner, but Now on Tap figured out the correct time and date for them. For example, when watching a YouTube video, you can hold the Home button to launch Now on Tap and it will give you related content and events!

Now on Tap works on top of most apps with no changes needed. If you want to make sure that Now on Tap works seamlessly on top of your app, make sure to check out "Optimizing Content for the Assistant" here. To make your app show up in Now on Tap links, use App Indexing.

Categories: Programming

What Is The Most Efficient Way To Read Books?

Making the Complex Simple - John Sonmez - Thu, 03/10/2016 - 14:00

What Is The Most Efficient Way To Read Books? Most people think that only reading books will change their lives. However, most people don’t even absorb any information of the books they read. Besides that, it is normal for people to simply discard the entire book once they’re faced with some information they disagree. So, what […]

The post What Is The Most Efficient Way To Read Books? appeared first on Simple Programmer.

Categories: Programming

Change to Mail Service in Apps Script

Google Code Blog - Wed, 03/09/2016 - 17:45

Originally posed Google Apps Developers Blog

Posted by Saurabh Gupta, Product Manager, Google Apps Script

There are two ways to send email in Apps Script: MailApp's sendEmail and GmailApp's sendEmail method. One of the differences between these two methods is that the MailApp’s sendEmail method doesn’t require the developer to be a Gmail user. For example, a Google Apps customer who doesn’t use Gmail, but uses Apps Script instead, can send emails through MailApp but not GmailApp.

Starting on September 13, 2016, users with free public Google Accounts (consumers) and Google Apps for Education and Google Apps Free edition users, will be required to have Gmail access to send messages through Apps Script’s Mail Service. Consumers can enable Gmail on their Google account after signing-in—note your Gmail will then become the primary address of your Google account. Administrators of Google Apps domains (Education and Free edition only) can use the Admin console to turn on Gmail for their domain.

This change does not require any updates to your code. You can continue to use MailApp as before; just make sure that you have signed up for Gmail. We realize that sometimes these changes are disruptive to our developers, but we can assure you that we put lot of care and deliberation into this process.

Categories: Programming

Agile Transformation - Keys to Success

10x Software Development - Steve McConnell - Wed, 03/09/2016 - 15:44

I wanted to let you know that I've posted a two-part series on Construx's experience with Agile Transformations, pitfalls, keys to success, and so on. 

The videos focus on two models that describe the transformation issues we have seen on the ground. You might have seen one or both of the models before, but they aren't often applied specifically to Agile adoption work. The focus of the videos is on showing how these general models specifically apply to Agile transformations. We have found that these models predict very well the challenges to expect in a transformation initiative and contain good insights into how to successfully overcome the challenges. 

Part 1: Agile Transformation - Change Model

Part 2: Agile Transformation - Adoption Model

Check out the talks!

Agile Transformation - Keys to Success - Two Part Series by Steve McConnell

What Programmers Can Learn from Golfing Legend Moe Norman

Making the Complex Simple - John Sonmez - Wed, 03/09/2016 - 14:00

If I were to ask you “Who is Tiger Woods?”, chances are you would tell me he is the greatest golfer in recent history, or maybe even the greatest of all time. Or, you might mention his fall from grace at the turn of the last decade. Either way, you’ve likely heard of him whether […]

The post What Programmers Can Learn from Golfing Legend Moe Norman appeared first on Simple Programmer.

Categories: Programming

Temporary Post Used For Theme Detection (071789ad-9ee2-41fd-a8d2-1664f4b7f31c – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

This is a temporary post that was not deleted. Please delete this manually. (d512d7c8-29a3-46fe-9c81-34e3751f1dcf – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Categories: Architecture, Programming

How many builds?

Actively Lazy - Tue, 03/08/2016 - 21:38

I’m always amazed at the seemingly high pain threshold .net developers have when it comes to tooling. I’ve written before about the poor state of tooling in .net, but just recently I hit another example of poor tooling that infuriates me: I have too many builds, and they don’t agree whether my code compiles.

One of the first things that struck me when starting to develop on .net was that compiling code was still a thing. An actual step that had to be thought about. Incremental compilers in Eclipse and the like have been around for ages – to the point where, generally, Java developers don’t actually have to instruct their IDE to compile code for them. But in Visual Studio? Oh it’s definitely necessary. And time consuming. Oh my god is it slow. Ok, maybe not as slow as Scala. But still unbelievably slow when you’re used to working at the speed of thought.

Another consequence of the closed, Microsoft way of doing things is that tools can’t share the compiler’s work. So ReSharper have implemented their own compiler, effectively. It incrementally parses source code and finds compiler errors. Sometimes it even agrees with the Visual Studio build. But all too often it doesn’t. From the spurious not-actually-an-error that I have to continually instruct ReSharper to ignore; to the warnings-as-errors build failures that ReSharper doesn’t warn me about; to the random why-does-ReSharper-not-know-about-that-NuGet-package-errors.

This can be infuriating when refactoring. E.g. if an automated refactor leaves a variable unused, I will now have a compiler warning; since all my projects run with warnings-as-errors switched on, this will fail the build. But ReSharper doesn’t know that. So I apply the refactoring, code & tests are green: commit. Push. Boom! CI is red. But it was an automated refactor for chrissakes, how’ve I broken the build?!

I also use NCrunch, an automated test runner for Visual Studio (like Infinitest in the Java world). NCrunch is awesome, by the way; better even than the continuous test runner in ReSharper 10. If you’ve never used a continuous test runner and think you’re doing TDD, sort your life out and setup Infinitest or NCrunch. It doesn’t just automate pressing the shortcut key to run all your tests. Well, actually that is exactly what it does – but the impact it has on your workflow is so much more than that. When you can type a few characters, look at the test output and see what happened you get instant feedback. This difference in degree changes the way you write code and makes it so much easier to do TDD.

Anyway I digress – NCrunch, because Microsoft, can’t use the result of the compile that Visual Studio does. So it does its own. It launches MSBuild in the background, continually re-compiling your code. This is not exactly kind on your CPU. It also introduces inconsistencies. Because NCrunch is running a slightly different MSBuild on each project to the build VisualStudio does you get subtly different results sometimes; which is different again from ReSharper with its own compiler that isn’t even using MSBuild. I now have three builds. Three compilers. It is honestly a miracle when they all agree that my code compiles.

An all-too-typical dev cycle becomes:

  • Write test
  • ReSharper is happy
  • NCrunch build is failing, force reload NCrunch project
  • NCrunch builds, test fails
  • Make test pass
  • Try to run app
  • VisualStudio build fails
  • Fix NuGet problems
  • NCrunch build is now failing
  • Force NCrunch to reload at least one project again
  • Force VisualStudio to rebuild the project
  • Then the solution
  • Run app to sanity check change
  • ReSharper now shows error
  • Re-ignore perennial ReSharper non-error
  • All three compilers agree, quick: commit!

Normally then the build fails in CI because I still screwed up the NuGet packages.

Then recently, as if this wasn’t already one of the outer circles of hell. The CI build was failing for a bizarre reason. We have a command line script which applies the same build steps that CI runs, so I thought I’d run that to replicate the problem. Unfortunately the command line build was failing on my machine for a spectacularly spurious reason that was different again than the failure in CI. Great. I now have five builds which don’t all agree on whether my code compiles.

Do you really hate computers? Do you wish you had more reasons to defenestrate every last one of them? Have you considered a career in software development?

Categories: Programming, Testing & QA

Digital Transformation is Business Transformation

Digital Transformation is everywhere.   It’s easy to let the tail wag the dog, especially when you are in the face of disruption.

But great and meaningful change always goes back to strategy.

In fact, if you really think about it, a lot of digital disruption is rooted in simple strategies for creating and capturing value at the edge, shifting power to users and consumers, reducing friction, and driving extreme efficiencies as new customer segments are created, new markets are forged, and the market seeks the dominant design.

Fundamentally, Digital Business Transformation is the digitization of business.  But as part of digitizing, you need to know WHY and WHAT you are digitizing before getting lost in the HOW of digitization.

To survive and thrive in the digital age, it helps to have a handle on how to think about the landscape and how to play the game.

In Digital Transformation Dr. Mark Baker shares how different consulting companies and business leaders are thinking about Digital Business Transformation.

Business Strategy for the Digital World

PwC is in the leadership quadrant because rather than focus on a digital strategy for the business world, they focus on a business strategy for the digital world.  I can relate to this because I’m on a team where we put business before technology.  This means fundamentally thinking about market trends, business drivers, business outcomes and investment objectives to shape the Digital Business Transformation approach.

Via Digital Transformation:

“PwC Consulting, if you look at the Gartner reports, or if you look at the Forrester reports, you’d see that they’d been doing a lot of work in the space over the past few years and are positioned in the leader’s quadrant.  Some of the reasons for being in the leader’s quadrant for PwC is because they’ve done something remarkably well and I really, really like the philosophy and that’s why I joined PwC.  It’s because that they believe that, you know, we don’t need the digital strategy.  What we require is a business strategy for the digital world and it just makes so much sense.”

Customer Journeys are Changing—How Do I Engage with My Customers?

One way to keep your bearings in the Digital Age from a business leader standpoint is to remember that your customer is your North Star.  A business exists to create a customer, as Peter Drucker puts it.

It’s easy to get lost in trying to implement multi-channel this, or API structure that, but those aren’t the real questions.  According to PwC, the real questions to drive your Digital Transformation start with recognizing that your customers demand new ways of learning about , trying, exploring, adopting, and socializing your products and services now.  So the real question is how do you connect and engage with your customers in relevant ways.  Once you shift your focus to your customer and their journey, now you can align your technical capabilities to support your key decisions that directly address your customer’s pains, needs, and desired outcomes.

Via Digital Transformation:

“So I think when we talk about PwC and their philosophy for digital, what they’re really saying is a digital strategy perhaps is limiting the impact of digital in today’s world.  It’s really a business strategy for the digital age and we do know that the digital age is here to stay for a considerable long time and it’s not about saying, ‘Hey, how do I have a multi-channel strategy or you know, how do I, you know, choose to go with an API structure?’  These are not the questions that are really being asked. 

The questions that are really being asked are…you know, ‘Customer journeys are changing today because of what digital has done, and therefor, my acquisition or my retention, you know, frameworks, or the way I’m going to go out and engage with my customers, needs to change.  So can you help me to manage this change?’  So there’s a difference between the two things to say, ‘Here’s a digital strategy,’  ‘Here’s a multichannel strategy’ while on the other hand you’re saying, ‘Hey, how do I actually…’ The same questions, but asked for the digital age and I think there’s great merit in that position.  So that’s all about PwC Consulting and their take on digital.’”

Digital is Greater than the Sum of All Parts

Digital Transformation cuts across the board and spans your business.   A simple way to think of it is to think in terms of the impact on customer experience transformation, employee or workforce transformation, and operations transformation.    Your customer experience transformation spans your value chain.  Your value chain connects your customer to product or service, supported by your business capabilities, which in turn are supported by technical capabilities.   And as you evolve your value chain to better support customers, you also change how your workforce interacts with customers, partners, and each other.  And as you evolve your workforce, you evolve your operations, and you innovate as you find ways to do things better, faster, and cheaper.

As you can imagine, you can’t just look at one business function or one piece of the business.  You need to take a whole business view to better understand how Digital has a ripple effect across the entire business, and how the sum of the digital change is more than the parts.

Via Digital Transformation:

“So digital isn’t a part of a division.  Digital is greater than the sum of all parts.  As we’ll see as we progress, if change is inevitable, it’s likely to be transformative and revolutionary rather than incremental and evolutionary in many cases, and there is likely to be disruption and resistance.  That doesn’t man that if it is planned ahead, like expert surgery, or a space mission, it can’t be mitigated in such a way that no individual step is traumatic, and the appearance of an incremental, stepwise process is retained.”

Digital Transformation is here.  You can run from it, or you can embrace it and re-imagine how you can lead your business in a mobile-first, cloud-first world.


Categories: Architecture, Programming

Apply now to join us and celebrate our #love4dev at #io16

Google Code Blog - Tue, 03/08/2016 - 18:00

Published by Mike Pegg, Head of Developer Marketing

One day in June of 2006 a very special thing happened. For the first time ever, we invited a handful of developers to spend the day with us at Google celebrating what they had achieved with our Maps APIs. Our engineering team came all the way from the Sydney office to help answer questions from developers, and help them learn new ways to solve problems in the apps they were building.

What a difference a decade makes. We’re absolutely amazed with all that developers from around the world have created and changed since that day in 2006. We’ve enjoyed this journey with you, and as developers ourselves we continue to be excited by the challenges that lie ahead.

It was this thinking that drove us to bring I/O back to where it all started 10 years ago and to continue celebrating this developer journey we’re on together. We’re really excited for I/O 2016 and we hope this year’s festival, happening May 18-20 at Shoreline Amphitheatre, is just as special as that first gathering at Google back in 2006.

We know a lot has changed over the years and the opportunities (and challenges) are even greater today than they were back then. We’re gearing up for an I/O festival that will celebrate your accomplishments, answer your burning technical questions, and hopefully help make your life as a developer a little bit easier. We hope you can join us! Applications for attendance opened today and will remain open until 3/10, 5PM PST. And in the meantime, share your #love4dev back with us.

Categories: Programming

How To Engineer Your ‘Lucky Break’

Making the Complex Simple - John Sonmez - Mon, 03/07/2016 - 14:00

To most, luck is about rolling the dice, finding a dollar on the ground, or having all your tests pass after a last-minute code commit. Luck is given credit for many people’s struggles and accomplishments. Some use bad luck as a reason for their current failure. At the same time, some might credit good luck […]

The post How To Engineer Your ‘Lucky Break’ appeared first on Simple Programmer.

Categories: Programming

Introducing Analytics for Google Cast Applications

Google Code Blog - Fri, 03/04/2016 - 20:00

Posted by Chris Dolan, Software Engineer on the Google Cast Server Infrastructure Team

As a Google Cast developer, you may be wondering how many devices access your application, how many sessions those devices initiate, and how long those sessions play media. Until now, you needed to implement your own instrumentation to get this information. Not anymore! Today, we’re excited to announce that we’re making all this data available right from the Google Cast Developer Console.

To check it out, log on as usual to the developer console with your developer account. In the ‘Application’ table, click on the ‘View’ link in the new ‘Statistics’ column for your application

Caption: The applications page showing a single app with the ‘View’ link called out

The analytics page contains a tab for each metric, an interactive graph of the metric’s values over time, and tables containing the most recent day’s data. The devices tab shows the number of Cast devices that have launched your application, the sessions tab shows the number of Cast sessions of your application, and the average playback tab shows the average length of media playback time per session for your *application.

The analytics page showing the tabs, graph, and tables of data

Each tab’s data can be viewed in total, by country, or by sender platform. To see data for a particular country or platform, simply click the appropriate row in the table. Each tab’s data is available on a per-day basis, as well as in seven, fourteen, and twenty-eight day rolling totals. To change the aggregation range, select the desired range from the range picker at the top right.

We hope these analytics give you insight into how your Google Cast applications are being used and enable you to see the impact of your improvements. To learn more, see the developer documentation.

* Applications that do not play media will have no average media playback
Categories: Programming

We Hire the Best, Just Like Everyone Else

Coding Horror - Jeff Atwood - Fri, 03/04/2016 - 13:17

One of the most common pieces of advice you'll get as a startup is this:

Only hire the best. The quality of the people that work at your company will be one of the biggest factors in your success – or failure.

I've heard this advice over and over and over at startup events, to the point that I got a little sick of hearing it. It's not wrong. Putting aside the fact that every single other startup in the world who heard this same advice before you is already out there frantically doing everything they can to hire all the best people out from under you and everyone else, it is superficially true. A company staffed by a bunch of people who don't care about their work and aren't good at their jobs isn't exactly poised for success. But in a room full of people giving advice to startups, nobody wants to talk about the elephant in that room:

It doesn't matter how good the people are at your company when you happen to be working on the wrong problem, at the wrong time, using the wrong approach.

Most startups, statistically speaking, are going to fail.

And they will fail regardless of whether they hired "the best" due to circumstances largely beyond their control. So in that context does maximizing for the best possible hires really make sense?

Given the risks, I think maybe "hire the nuttiest risk junkie adrenaline addicted has-ideas-so-crazy-they-will-never-work people you can find" might actually be more practical startup advice. (Actually, now that I think about it, if that describes you, and you have serious Linux, Ruby, and JavaScript chops, perhaps you should email me.)

I told that person the same thing I tell all prospective job candidates: "come with me if you want to live"

— Jeff Atwood (@codinghorror) May 24, 2015

Okay, the goal is to increase your chance of success, however small it may be, therefore you should strive to hire the best. Seems reasonable, even noble in its way. But this pursuit of the best unfortunately comes with a serious dark side. Can anyone even tell me what "best" is? By what metrics? Judged by which results? How do we measure this? Who among us is suitable to judge others as the best at … what, exactly? Best is an extreme. Not pretty good, not very good, not excellent, but aiming for the crème de la crème, the top 1% in the industry.

The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.

Pursuit of this extreme means hiring anyone less than the best becomes unacceptable, even harmful:

In the Macintosh Division, we had a saying, “A players hire A players; B players hire C players” – meaning that great people hire great people. On the other hand, mediocre people hire candidates who are not as good as they are, so they can feel superior to them. (If you start down this slippery slope, you’ll soon end up with Z players; this is called The Bozo Explosion. It is followed by The Layoff.) — Guy Kawasaki

There is an opportunity cost to keeping someone when you could do better. At a startup, that opportunity cost may be the difference between success and failure. Do you give less than full effort to make your enterprise a success? As an entrepreneur, you sweat blood to succeed. Shouldn’t you have a team that performs like you do? Every person you hire who is not a top player is like having a leak in the hull. Eventually you will sink. — Jon Soberg

Why am I so hardnosed about this? It’s because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees. And they might be bad programmers but really nice people or maybe they really need this job, so you can’t bear to fire them, or you can’t fire them without pissing everybody off, or whatever. It’s just a bad scene.

On the other hand, if you reject a good candidate, I mean, I guess in some existential sense an injustice has been done, but, hey, if they’re so smart, don’t worry, they’ll get lots of good job offers. Don’t be afraid that you’re going to reject too many people and you won’t be able to find anyone to hire. During the interview, it’s not your problem. Of course, it’s important to seek out good candidates. But once you’re actually interviewing someone, pretend that you’ve got 900 more people lined up outside the door. Don’t lower your standards no matter how hard it seems to find those great candidates. — Joel Spolsky

I don't mean to be critical of anyone I've quoted. I love Joel, we founded Stack Overflow together, and his advice about interviewing and hiring remains some of the best in the industry. It's hardly unique to express these sort of opinions in the software and startup field. I could have cited two dozen different articles and treatises about hiring that say the exact same thing: aim high and set out to hire the best, or don't bother.

This risk of hiring not-the-best is so severe, so existential a crisis to the very survival of your company or startup, the hiring process has to become highly selective, even arduous. It is better to reject a good applicant every single time than accidentally accept one single mediocre applicant. If the interview process produces literally anything other than unequivocal "Oh my God, this person is unbelievably talented, we have to hire them", from every single person they interviewed with, right down the line, then it's an automatic NO HIRE. Every time.

This level of strictness always made me uncomfortable. I'm not going to lie, it starts with my own selfishness. I'm pretty sure I wouldn't get hired at big, famous companies with legendarily difficult technical interview processes because, you know, they only hire the best. I don't think I am one of the best. More like cranky, tenacious, and outspoken, to the point that I wake up most days not even wanting to work with myself.

If your hiring attitude is that it's better to be possibly wrong a hundred times so you can be absolutely right one time, you're going to be primed to throw away a lot of candidates on pretty thin evidence.

Before cofounding GitHub I applied for an engineering job at Yahoo and didn’t get it. Don’t let other people discourage you.

— Chris Wanstrath (@defunkt) May 22, 2014

I've been twitter following the careers of people we interviewed but passed on at my last gig.

Turns out we were almost always wrong.

— Trek Glowacki (@trek) January 26, 2016

Perhaps worst of all, if the interview process is predicated on zero doubt, total confidence … maybe this candidate doesn't feel right because they don't look like you, dress like you, think like you, speak like you, or come from a similar background as you? Are you accidentally maximizing for hidden bias?

One of the best programmers I ever worked with was Susan Warren, an ex-Microsoft engineer who taught me about the People Like Us problem, way back in 2004:

I think there is a real issue around diversity in technology (and most other places in life). I tend to think of it as the PLU problem. Folk (including MVPs) tend to connect best with folks most like them ("People Like Us"). In this case, male MVPs pick other men to become MVPs. It's just human nature.

As one reply notes, diversity is good. I'd go as far as to say it's awesome, amazing, priceless. But it's hard to get to -- the classic chicken and egg problem -- if you rely on your natural tendencies alone. In that case, if you want more female MVPs to be invited you need more female MVPs. If you want more Asian-American MVPs to be invited you need more Asian-American MVPs, etc. And the (cheap) way to break a new group in is via quotas.

IMO, building diversity via quotas is bad because they are unfair. Educating folks on why diversity is awesome and how to build it is the right way to go, but also far more costly.

Susan was (and is) amazing. I learned so much working under her, and a big part of what made her awesome was that she was very much Not Like Me. But how could I have appreciated that before meeting her? The fact is that as human beings, we tend to prefer what's comfortable, and what's most comfortable of all is … well, People Like Us. The effect can be shocking because it's so subtle, so unconscious – and yet, surprisingly strong:

  • Baseball cards held by a black hand consistently sold for twenty percent less than those held by a white hand.

  • Using screens to hide the identity of auditioning musicians increased women's probability of advancing from preliminary orchestra auditions by fifty percent.

  • Denver police officers and community members were shown rapidly displayed photos of black and white men, some holding guns, some holding harmless objects like wallets, and asked to press either the "Shoot" or "Don't Shoot" button as fast as they could for each image. Both the police and community members were three times more likely to shoot black men.

It's not intentional, it's never intentional. That's the problem. I think our industry needs to shed this old idea that it's OK, even encouraged to turn away technical candidates for anything less than absolute 100% confidence at every step of the interview process. Because when you do, you are accidentally optimizing for implicit bias. Even as a white guy who probably fulfills every stereotype you can think of about programmers, and who is in fact wearing an "I Rock at Basic" t-shirt while writing this very blog post*, that's what has always bothered me about it, more than the strictness. If you care at all about diversity in programming and tech, on any level, this hiring approach is not doing anyone any favors, and hasn't been. For years.

I know what you're thinking.

Fine, Jeff, if you're so smart, and "hiring the best" isn't the right strategy for startups, and maybe even harmful to our field as a whole, what should be doing?

Well, I don't know, exactly. I may be the wrong person to ask because I'm also a big believer in geographic diversity on top of everything else. Here's what the composition of the current Discourse team looks like:

I would argue, quite strongly and at some length, that if you want better diversity in the field, perhaps a good starting point is not demanding that all your employees live within a tiny 30 mile radius of San Francisco or Palo Alto. There's a whole wide world of Internet out there, full of amazing programmers at every level of talent and ability. Maybe broaden your horizons a little, even stretch said horizons outside the United States, if you can imagine such a thing.

I know hiring people is difficult, even with the very best of intentions and under ideal conditions, so I don't mean to trivialize the challenge. I've recommended plenty of things in the past, a smorgasboard of approaches to try or leave on the table as you see fit:

… but the one thing I keep coming back to, that I believe has enduring value in almost all situations, is the audition project:

The most significant shift we’ve made is requiring every final candidate to work with us for three to eight weeks on a contract basis. Candidates do real tasks alongside the people they would actually be working with if they had the job. They can work at night or on weekends, so they don’t have to leave their current jobs; most spend 10 to 20 hours a week working with Automattic, although that’s flexible. (Some people take a week’s vacation in order to focus on the tryout, which is another viable option.) The goal is not to have them finish a product or do a set amount of work; it’s to allow us to quickly and efficiently assess whether this would be a mutually beneficial relationship. They can size up Automattic while we evaluate them.

What I like about audition projects:

  • It's real, practical work.
  • They get paid. (Ask yourself who gets "paid" for a series of intensive interviews that lasts multiple days? Certainly not the candidate.)
  • It's healthy to structure your work so that small projects like this can be taken on by outsiders. If you can't onboard a potential hire, you probably can't onboard a new hire very well either.
  • Interviews, no matter how much effort you put into them, are so hit and miss that the only way to figure out if someone is really going to work in a given position is to actually work with them.

Every company says they want to hire the best. Anyone who tells you they know how to do that is either lying to you or to themselves. But I can tell you this: the companies that really do hire the best people in the world certainly don't accomplish that by hiring from the same tired playbook every other company in Silicon Valley uses.

Try different approaches. Expand your horizons. Look beyond People Like Us and imagine what the world of programming could look like in 10, 20 or even 50 years – and help us move there by hiring to make it so.

* And for the record, I really do rock at BASIC.

[advertisement] Building out your tech team? Stack Overflow Careers helps you hire from the largest community for programmers on the planet. We built our site with developers like you in mind.
Categories: Programming

Coffee with a Googler talks Identity with Adam Dawes

Google Code Blog - Thu, 03/03/2016 - 23:22

Posted by Laurence Moroney, Developer Advocate

Coffee with a Googler catches up with Adam Dawes, leader of Google’s Federated Identity team. His team builds seamless identity experiences for users. He tells us about Google Sign-In, and the simplifications to the APIs, focusing on decoupling from the Google+ sign-in to make the user experience more streamlined.

The landscape for users has changed over the last few years, and the user’s expectation of information that they provide for signing in is very different now. Adam shares about how his team have been engineering sign in APIs to meet these needs.

Adam demonstrates the new APIs using the runkeeper app as an example, and how it avoids ‘cognitive overload.’

We learn about OpenID connect, to make it super simple to use the authentication APIs with your own backend servers. It’s a much simpler experience, so that if all you want to do is sign the user in, without social, we made it simpler for you to do so.

One question we’ve had extensively is with using iOS apps with Google Sign-In. Adam shares how Google Sign-In uses the new Safari View Controller in iOS 9 to ensure that the API will work well on iOS.

To learn more about all these offerings, visit developers.google.com/identity.

Categories: Programming

Successful Programmer Mindset: Don’t Be F***** Lazy!

Making the Complex Simple - John Sonmez - Thu, 03/03/2016 - 14:00

You feel like you can’t go on with your life. You feel trapped and nothing that you do seems to work. You’re trapped inside of your own life. You have work, school, family and friends to deal with. And you don’t see a way out of this… WHAT SHOULD I DO JOHN? Well, there are a […]

The post Successful Programmer Mindset: Don’t Be F***** Lazy! appeared first on Simple Programmer.

Categories: Programming