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&page=1' 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!

Feed aggregator
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.

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Herding Cats - Glen Alleman - Wed, 04/27/2016 - 04:55

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (not de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considered those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz word without knowing what they actually mean.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made with estimates,” and continue on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money
2. Unrealistic cost and schedule estimates – the source of poor estimating
3. Inadequate assessment of unmitigated risk exposure
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

Coach or Manager?

20130520-220059.jpg

Are you a coach or a manager? Most traditional, hierarchical IT organizations use managers to plan, organize and control work. Managers make decisions with greater or lesser collaboration, based on their management style. A coach is a different thing entirely. Coaches exist to assist a team to reach its full potential. In the world of empowered employees and self-managed teams, a coach is an enabler, a guide, and a leader.

A coach enables her team by suggesting areas for self-improvement, ideas for using tools and techniques and facilities improving team. The goal of coaching is to help the team become more effective in delivering value to the organization. The act of coaching requires the ability to interact and facilitate both how individuals and groups work within the team.

When a coach provides guidance, they are using their gravitas to influence the direction of the team. In organizations that rely on control environments, the manager will tell the team the correct direction with the expectation that telling and doing are sequential acts. A coach provides direction and uses her influence to get the team to internalize that direction. The internalized direction may well reflect a synthesis of the team’s knowledge and the coach’s advice.

The ability to enable and guide is a function of being a leader. Kevin Kruse, author of Employee Engagement 2.0, defines leadership as “a process of social influence, which maximizes the efforts of others, towards the achievement of a goal.” The definition does not include the primary tenants of the definition of a manager, control and positional authority, but rather is focused on getting the most from the team through influence.

A coach is a guide and a leader. These attributes are inter-related and self-reinforcing. A coach rarely needs to leverage the techniques of a manager – planning, organizing and directing – rather they rely on influence and team peer-pressure. Are you a manager or a coach? The distinction is stark. Is your role to help the team maximize its value through a process of facilitation? If the answer is yes, then you are a coach.


Categories: Process Management

Android Studio 2.1 supports Android N Developer Preview

Android Developers Blog - Tue, 04/26/2016 - 22:49

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.
  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.


N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What's Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

Categories: Programming

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Herding Cats - Glen Alleman - Tue, 04/26/2016 - 21:50

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considered those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz word without knowing what they actually mean.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made with estimates,” and continue on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money
2. Unrealistic cost and schedule estimates – the source of poor estimating
3. Inadequate assessment of unmitigated risk exposure
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

SE-Radio Episode 255: Monica Beckwith on Java Garbage Collection

Monica Beckwith joins Robert Blumen for a discussion of java garbage collection. What is garbage collection? GC algorithms; history of GC in the java language; fragmentation and compaction; generational strategies; causes of pauses; impact of pauses on application performance; tuning GC; GC on multi-core and large memory machines; should production servers be implemented in non-GC […]
Categories: Programming

Sponsored Post: Aerospike, TrueSight Pulse, Redis Labs, InMemory.Net, VividCortex, MemSQL, Scalyr, AiScaler, AppDynamics, ManageEngine, Site24x7

Who's Hiring?
  • Software Engineer (DevOps). You are one of those rare engineers who loves to tinker with distributed systems at high scale. You know how to build these from scratch, and how to take a system that has reached a scalability limit and break through that barrier to new heights. You are a hands on doer, a code doctor, who loves to get something done the right way. You love designing clean APIs, data models, code structures and system architectures, but retain the humility to learn from others who see things differently. Apply to AppDynamics

  • Software Engineer (C++). You will be responsible for building everything from proof-of-concepts and usability prototypes to deployment- quality code. You should have at least 1+ years of experience developing C++ libraries and APIs, and be comfortable with daily code submissions, delivering projects in short time frames, multi-tasking, handling interrupts, and collaborating with team members. Apply to AppDynamics
Fun and Informative Events
  • Discover the secrets of scalability in IT. The cream of the Amsterdam and Berlin tech scene are coming together during TechSummit, hosted by LeaseWeb for a great day of tech talk. Find out how to build systems that will cope with constant change and create agile, successful businesses. Speakers from SoundCloud, Fugue, Google, Docker and other leading tech companies will share tips, techniques and the latest trends in a day of interactive presentations. But hurry. Tickets are limited and going fast! No wonder, since they are only €25 including lunch and beer.

  • How can your business stand out from the crowd? Bringing to market an innovative differentiation – without too many technical challenges – can be the key. The most forward-looking organizations are coding business logic using the fastest, most agile and scalable technologies available today. In a webinar on May 11 entitled “Exposing Differentiation: A New Era of Scalable Infrastructure Arrives”, Data Scientist Dez Blanchfield and Chief Analyst Dr. Robin Bloor will explain how a nexus of innovations has transformed what’s possible. They’ll be briefed by Brian Bulkowski, CTO and Co-Founder of Aerospike (the high-performance NoSQL database), who will discuss how leading companies are changing their infrastructure to meet the new demands of customized digital experiences, fraud prevention, risk analysis, and other application and data uses. Sign up here to reserve your seat!
Cool Products and Services
  • TrueSight Pulse is SaaS IT performance monitoring with one-second resolution, visualization and alerting. Monitor on-prem, cloud, VMs and containers with custom dashboards and alert on any metric. Start your free trial with no code or credit card.

  • Turn chaotic logs and metrics into actionable data. Scalyr is a tool your entire team will love. Get visibility into your production issues without juggling multiple tools and tabs. Loved and used by teams at Codecademy, ReturnPath, and InsideSales. Learn more today or see why Scalyr is a great alternative to Splunk.

  • InMemory.Net provides a Dot Net native in memory database for analysing large amounts of data. It runs natively on .Net, and provides a native .Net, COM & ODBC apis for integration. It also has an easy to use language for importing data, and supports standard SQL for querying data. http://InMemory.Net

  • VividCortex measures your database servers’ work (queries), not just global counters. If you’re not monitoring query performance at a deep level, you’re missing opportunities to boost availability, turbocharge performance, ship better code faster, and ultimately delight more customers. VividCortex is a next-generation SaaS platform that helps you find and eliminate database performance problems at scale.

  • MemSQL provides a distributed in-memory database for high value data. It's designed to handle extreme data ingest and store the data for real-time, streaming and historical analysis using SQL. MemSQL also cost effectively supports both application and ad-hoc queries concurrently across all data. Start a free 30 day trial here: http://www.memsql.com/

  • aiScaler, aiProtect, aiMobile Application Delivery Controller with integrated Dynamic Site Acceleration, Denial of Service Protection and Mobile Content Management. Also available on Amazon Web Services. Free instant trial, 2 hours of FREE deployment support, no sign-up required. http://aiscaler.com

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • www.site24x7.com : Monitor End User Experience from a global monitoring network.

If any of these items interest you there's a full description of each sponsor below...

Categories: Architecture

Software Development Conferences Forecast April 2016

From the Editor of Methods & Tools - Tue, 04/26/2016 - 10:09
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

Quote of the Day

Herding Cats - Glen Alleman - Tue, 04/26/2016 - 05:33

For the great enemy of truth is very often not the lie ― deliberate, contrived, and dishonest ― but the myth ― persistent, persuasive, and unrealistic. Too often we hold fast to the clichés of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought. ― John F. Kennedy

Take care when you hear any opinion not based on principles, for you are succumbing to those opinions produced by personal anecdotes - untested outside that personal experience - are the basis of myth. When those making those untested personal anecdotal conjectures vigorously criticize those asking for evidence, be more careful. For the smell comes from the propagation of the myth not the facts. 

Related articles Good Project and Bad Project How We Make Decisions is as Important as What We Decide. The Cognitive Illusion of Bad Software Project Outcomes Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Protecting against unintentional regressions to cleartext traffic in your Android apps

Android Developers Blog - Mon, 04/25/2016 - 22:30

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com. HTTPS, Android-Security

Categories: Programming

[New eBook] Download The No-Nonsense Guide to In-App Ads

Google Code Blog - Mon, 04/25/2016 - 21:23

Originally Posted on Inside AdMob Blog


Posted by Joe Salisbury, Product Specialist, AdMob
A clear trend is emerging in the world of smartphones – people want free apps. According to a study by Juniper Research, barely 1% of apps are now paid for at the point of download.1

While demand for free apps continues to increase, app developers are answering a very important question, “what’s the best way to publish my app for free while sustainably funding my business?”

In-app ads are a reliable solution that is set to grow 3.2X between 2014-18. 2

Many of the world’s most popular apps rely heavily on in-app advertising to earn income. Apps like PicsArts and Trivia Crack each have hundreds of millions of downloads and use advertising as a revenue source. In-app ads are evolving and there are many options for developers to utilize which provide great experiences for users.

So, how do you get started with ads?

To answer this, we’re launching a new ebook called “The No-nonsense Guide to In-App Ads”, the latest in our No-nonsense series. This guide is designed to provide a comprehensive overview of in-app advertising for those new to the opportunity. We’ll walk you through how digital ads can be included into your app strategy and what’s the best way for you to get started.

In the eBook, you’ll learn:

  • Foundational advertising concepts like eCPM, Fill Rate, Demand, and Inventory.
  • A simple overview of how businesses make money from advertising. 
  • How Pay Per Click advertising works.
  • A basic explanation of ad networks and how they can help you monetize your app.
  • How to choose the right ad network for your app.

Download a free copy here.


For more tips on app monetization, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Posted by Joe Salisbury, Product Specialist, AdMob

1 - Juniper, April 2015 and Juniper website, The App Landscape Today, Feb 2015
2 - App Annie/IDC, April 2015, Mobile App Advertising and Monetization Trends 2013-2018
Categories: Programming

Layers, hexagons, features and components

Coding the Architecture - Simon Brown - Mon, 04/25/2016 - 21:02

This blog post is a follow-up to the discussions I've had with people after my recent Modular Monoliths talks. I've been enthusiastically told that the "ports & adapters" (hexagonal) architectural style is "vastly", "radically" and "hugely" different to a traditional layered architecture. I remain unconvinced, hence this blog post, which has a Java spin, but I'm also interested in how the concepts map to other programming languages. I'm also interested in exploring how we can better structure our code to prevent applications becoming big balls of mud. Layers are not the only option.

Setting the scene

Imagine you're building a simple web application where users interact with a web page and information is stored in a database. The UML class diagrams that follow illustrate some of the typical ways that the source code elements might be organised.

Some approaches to organising code in a simple Java web app

Let's first list out the types in the leftmost diagram:

  • CustomerController: A web controller, something like a Spring MVC controller, which adapts requests from the web.
  • CustomerService: An interface that defines the "business logic" related to customers, sometimes referred to in DDD terms as a "domain service". This may or may not be needed, depending on the complexity of the domain.
  • CustomerServiceImpl: The implementation of the above service.
  • CustomerDao: An interface that defines how customer information will be persisted.
  • JdbcCustomerDao: An implementation of the above data access object.

I'll talk about the use of interfaces later, but let's assume we're going to use interfaces for the purposes of dependency injection, substitution, testing, etc. Now let's look at the four UML class diagrams, from left to right.

  1. Layers: This is what a typical layered architecture looks like. Code is sliced horizontally into layers, which are used as a way to group similar types of things. In a "strict layered architecture", layers should only depend on lower layers. In Java, layers are typically implemented as packages. As you can see from the diagram, all layer (inter-package) dependencies point downwards.
  2. Hexagonal (ports & adapters): Thomas Pierrain has a great blog post that describes the hexagonal architecture, as does Alistair Cockburn of course. The essence is that the application is broken up into two regions: inside and outside. The inside region contains all of the domain concepts, whereas the outside region contains the interactions with the outside world (UIs, databases, third-party integrations, etc). One rule is that the outside depends on the inside; never the other way around. From a static perspective, you can see that the JdbcCustomerRepository depends on the domain package. Particularly when coupled with DDD, another rule is that everything on the inside is expressed in the ubiquitous language, so you'll see terms like "Repository" rather than "Data Access Object".
  3. Feature packages: This is a vertical slicing, based upon related features, business concepts or aggregate roots. In typical Java implementations, all of the types are placed into a single package, which is named to reflect the concept that is being grouped. Mark Needham has a blog post about this, and the discussion comments are definitely worth reading.
  4. Components: This is what I refer to as "package by component". It's similar to packaging by feature, with the exception that the application (the UI) is separate from the component. The goal is to bundle all of the functionality related to a single component into a single Java package. It's akin to taking a service-centric view of an application, which is something we're seeing with microservice architectures.
How different are these architectural styles?

On the face of it, these do all look like different ways to organise code and, therefore, different architectural styles. This starts to unravel very quickly once you start looking at code examples though. Take a look at the following example implementations of the ports & adapters style.

Spot anything? Yes, the interface (port) and implementation class (adapter) are both public. Most of the code examples I've found on the web have liberal usage of the public access modifier. And the same is true for examples of layered architectures. Marking all types as public means you're not taking advantage of the facilities that Java provides with regards to encapsulation. In some cases there's nothing preventing somebody writing some code to instantiate the concrete repository implementation, violating the architecture style. Coaching, discipline, code reviews and automated architecture violation checks in the build pipeline would catch this, assuming you have them. My experience suggests otherwise, especially when budgets and deadlines start to become tight. If left unchecked, this is what can turn a codebase into a big ball of mud.

Organisation vs encapsulation

Looking at this another way, when you make all types in your application public, the packages are simply an organisation mechanism (a grouping, like folders) rather than being used for encapsulation. Since public types can be used from anywhere in a codebase, you can effectively ignore the packages. The net result is that if you ignore the packages (because they don't provide any means of encapsulation and hiding), a ports & adapters architecture is really just a layered architecture with some different naming. In fact, if all types are public, all four options presented before are exactly the same.

Approaches without packages

Conceptually ports & adapters is different from a traditional layered architecture, but syntactically it's really the same, especially if all types are marked as public. It's a well implemented n-layer architecture, where n is the number of layers through a slice of the application (e.g. 3; web-domain-database).

Utilising Java's access modifiers

The way Java types are placed into packages can actually make a huge difference to how accessible (or inaccessible) those types can be when Java's access modifiers are applied appropriately. Ignoring the controllers ... if I bring the packages back and mark (by fading) those types where the access modifier can be made more restrictive, the picture becomes pretty interesting.

Access modifiers made more restrictive

The use of Java's access modifiers does provide a degree of differentiation between a layered architecture and a ports & adapters architecture, but I still wouldn't say they are "vastly" different. Bundling the types into a smaller number of packages (options 3 & 4) allows for something a little more radical. Since there are fewer inter-package dependencies, you can start to restrict the access modifiers. Java does allow interfaces to be marked as package protected (the default modifier) although if you do this you'll notice that the methods must still be marked as public. Having public methods on a type that's inaccessible outside of the package is a little odd, but it's not the end of the world.

With option 3, "vertical slicing", you can take this to the extreme and make all types package protected. The caveat here is that no other code (e.g. web controllers) outside of the package will be able to easily reuse functionality provided by the CustomerService. This is not good or bad, it's just a trade-off of the approach. I don't often see interfaces being marked as package protected, but you can use this to your advantage with frameworks like Spring. Here's an example from Oliver Gierke that does just this (the implementation is created by the framework). Actually, Oliver's blog post titled Whoops! Where did my architecture go, which is about reducing the number of public types in a codebase, is a recommended read.

I'm not keen on how the presentation tier (CustomerController) is coupled in option 3, so I tend to use option 4. Re-introducing an inter-package dependency forces you to make the CustomerComponent interface public again, but I like this because it provides a single API into the functionality contained within the package. This means I can easily reuse that functionality across other web controllers, other UIs, APIs, etc. Provided you're not cheating and using reflection, the smaller number of public types results in a smaller number of possible dependencies. Options 3 & 4 don't allow callers to go behind the service, directly to the DAO. Again, I like this because it provides an additional degree of encapsulation and modularity. The architecture rules are also simpler and easier to enforce, because the compiler can do some of this work for you. This echoes the very same design principles and approach to modularity that you'll find in a modern microservices architecture: a remotable service interface with a private implementation. This is no coincidence. Caveats apply (e.g. don't have all of your components share a single database schema) but a well-structured modular monolith will be easier to transform into a microservices architecture.

Testing

In the spirit of YAGNI, you might realise that some of those package protected DAO interfaces in options 3 and 4 aren't really necessary because there is only a single implementation. This post isn't about testing, so I'm just going to point you to Unit and integration are ambiguous names for tests. As I mention in my "Modular Monoliths" talk though, I think there's an interesting relationship between the architecture, the organisation of the code and the tests. I would like to see a much more architecturally-aligned approach to testing.

Conclusions?

I've had the same discussion about layers vs ports & adapters with a number of different people and opinions differ wildly as to how different the two approaches really are. A Google search will reveal the same thing, with numerous blog posts and questions on Stack Overflow about the topic. In my mind, a well implemented layered architecture isn't that different to a hexagonal architecture. They are certainly conceptually different but this isn't necessarily apparent from the typical implementations that I see. And that raises another interesting question: is there a canonical ports & adapters example out there? Of course, module systems (OSGi, Java 9, etc) change the landscape because they allow us to differentiate between public and published types. I wonder how this will affect the code we write and, in particular, whether it will allow us to build more modular monoliths. Feel free to leave a comment or tweet me @simonbrown with any thoughts.

Categories: Architecture

The Joy of Deploying Apache Storm on Docker Swarm

This is a guest repost from Baqend Tech on deploying and redeploying an Apache Storm cluster on top of Docker Swarm instead of deploying on VMs. It's an interesting topic because of the experience Wolfram Wingerath called it "a real joy", which is not a phrase you hear often in tech. Curious, I asked what made using containers such a good experience over using VMs? Here's his reply:

Being pretty new to Docker and Docker Swarm, I'm sure there are many good and bad sides I am not aware of, yet. From my point of view, however, the thing that makes deployment (and operation in general) on top of Docker way more fun than on VMs or even on bare metal is that Docker abstracts from heterogeneity and many issues. Once you have Docker running, you can start something like a MongoDB or a Redis server with a single-line statement. If you have a Docker Swarm cluster, you can do the same, but Docker takes care of distributing the thing you just started to some server in your cluster. Docker even takes care of downloading the correct image in case you don't have it on your machine right now. You also don't have to fight as much with connectivity issues, because every machine can reach every other machine as long as they are in the same Docker network. As demonstrated in the tutorial, this even goes for distributed setups, as long as you have an _overlay_ network.

 

When I wrote the lines you were quoting in your email, I had a situation in the back of my head that had occurred a few months back when I had to set up and operate an Apache Storm cluster with 16+ nodes. There were several issues such as my inexperience with AWS (coming from OpenStack) and strange connectivity problems relating to Netty (used by Storm) and AWS hostname resolution that had not occurred in my OpenStack setup and eventually cost us several days and several hundred bucks to fix. I really think that you can shield from problems like that by using Docker, simply because your environment remains the same: Docker.

On to the tutorial...
Categories: Architecture

Small-World Networks Article Posted

I’m a new contributor to the TechBeacon site. I have an article up, called Small-world networks: a lightweight alternative to SAFe for scaling agile.

 Scaling Collaboration Across the OrganizationYes, it’s based on Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Hope you enjoy the article.

Categories: Project Management

Governance and Estimating

Herding Cats - Glen Alleman - Mon, 04/25/2016 - 14:18

If your business is not subject to any external governance process, you’re free to spend your money as you please. But you’re not free to suggest your approach is applicable to those who are governed by external frameworks of spending and accountability for that spend, without a testable confirmation this idea doesn’t violate those governance principles.

Governance includes: Responsibility for a specific duty, task, or decision. Authority to influence behaviours. Communication of decisions. Empowerment to give individual's authority to act.

The governing of IT systems has two distinct components.

  1. A structural component that pertains to the organisation’s information technology activities, the way those activities support the goals of the business, and the people who help manage those activities.
  2. A process component that defines the decision-making rights associated with IT as well as the mechanisms and policies used to measure and control the way IT decisions are made and carried out within the organisation.

All businesses that operate inside governance frameworks, which address:

  • Risk, Conformance and Compliance - COSO, CoBit, ISO 27001, ISO 38500
  • Development Change control - ISO 12207, CMMI, CoBit, OPM3, Prince2
  • Information & Technology Balance Sheet - Balanced Scorecard, Zachman 
  • Operations - ITIL, ITPO, PCI DSS, BCM/BS25000, ISO 20000, TCO/ROI, ISO 27001, CoBit
  • Business Strategy - Balanced Scorecard

make use of estimates in their decision support processes. To suggest Not Estimating can be the basis of those decision making process is to willfully ignore these principles.

If it’s not your money, you don’t get to do as you please. If it’s your money, do as you please no one really cares. If it’s your customer’s money, confirm with them how they expect you to behave when spending that money.

Categories: Project Management

How Budding Programmers Can Get Their Work Noticed

Making the Complex Simple - John Sonmez - Mon, 04/25/2016 - 13:00

Parallel with the rising number of online tech solutions, the need for programmers is constantly growing. Today, in order to boost the information flow and workplace efficacy, almost every company needs a user-friendly website, an app or a highly optimized piece of software. In other words, never before was it easier and more lucrative to […]

The post How Budding Programmers Can Get Their Work Noticed appeared first on Simple Programmer.

Categories: Programming

Solving Agile portfolio planning for Lawns 'R' Us

Xebia Blog - Mon, 04/25/2016 - 09:28
Agile portfolio planning is a great (chief) product owner tool to plan and trace initiatives across various teams. Implementing it can be difficult and cumbersome at times. This post explores the number one critical success factor to do Agile portfolio planning right; Outcome oriented decision making. Outcome goals are valuable for streamlining your Agile portfolio

Satya Nadella on Digital Transformation

Satya posted his mental model for Digital Transformation:

image

I like the simplicity.

What I like is that there are four clear pillars or areas to look at for driving Digital Transformation:

  1. Customers
  2. Employees
  3. Operations
  4. Products

Collectively, these four Digital Transformation pillars set the stage for transforming your business model.

What I also like is that this matches what I learned while driving Digital Business Transformation with our field with customers, and as part of Satya’s innovation team.

Effectively, to generate new sources of revenue, organizations re-imagine their customer experience along their value chain.  As they connect and engage with their customers in new ways, this transforms their employee experience, and their operations.  As they gain new insight into their customers behavior and needs, they transform their products and services.

In a world of infinite compute and infinite storage…how would you re-imagine your business for a mobile-first, cloud-first world?

You Might Also Like

Digital Transformation is Business Transformation

How Leaders are Building Digital Skills

Microsoft Stories of Digital Business Transformation

Re-imagine Your Customer Experience

Re-imagine Your Operations

Categories: Architecture, Programming

SPaMCAST 391 – Mix Tape 2007 – 2008, McKnight, Iwanicki, Goldsmith

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The first full Software Process and Measurement Cast posted on January 29th, 2007.  When the first cast posted we were on an every other week schedule whereas today we post weekly.  Over the next few weeks, I will be traveling.  The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST.  In place of our normal format, I will post a mixtape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 – Will McKnight on Process and Product Quality Assurance

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 – Stasia Iwanicki on Six Sigma

Stasia used her first wish to address requirements capture, development, and management.  Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 – Robin Goldsmith on Requirements

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews.  Next week 2009!


Categories: Process Management

SPaMCAST 391 – Mix Tape 2007 – 2008, McKnight, Iwanicki, Goldsmith

Software Process and Measurement Cast - Sun, 04/24/2016 - 22:00

The first full Software Process and Measurement Cast posted on January 29th, 2007. When the first cast posted we were on an every other week schedule whereas today we post weekly. Over the next few weeks, I will be traveling. The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST. In place of our normal format, I will post a mixtape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 – Will McKnight on Process and Product Quality Assurance

http://bit.ly/1VBujvS

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 - Stasia Iwanicki on Six Sigma

http://bit.ly/1WdJnOP

Stasia used her first wish to address requirements capture, development, and management. Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 – Robin Goldsmith on Requirements

http://bit.ly/23ZC9Av

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews. Next week 2009!

Categories: Process Management

How to Save Your Business

NOOP.NL - Jurgen Appelo - Sun, 04/24/2016 - 14:00
how-to-save-your-business

When it comes to transforming their organizations, people often ask me the same silly questions.

Imagine a village of people who have successfully lived in a forest for hundreds of years. Some have grandiose tree houses; others have excavated spacious homes under the ground. Some villagers are specialized woodcutters; others prefer to hunt or gather nuts and fruit. And a few of the villagers are officials who take care of this small but thriving society. They see to it that all specialist jobs are adequately covered and that all are properly represented on the Village Council.

Recently, however, there has been some unrest in the village: There is a strong wind from the west and it carries with it the faint odor of… fire.

=8-C

This is a metaphor that we can use for almost every company that has made good money in the past and that is now facing the threat of eradication by globalization, innovation, and a relentless pace of change.

As a public speaker, I travel around the world quite a bit, and I encounter many of such villages, small and large. Fortunately, almost everyone I meet has realized that their village cannot escape the fire. To survive, the villagers will have to move elsewhere. But the people in these villages have a lot of questions for the traveling visitor:

Where is the environment safe?

Everywhere but here! The question assumes that there are safe and unsafe places for organizations to exist. Well, guess what? The world of business is changing faster and faster. Most places are variously safe and unsafe at different times. Fires, tsunamis, and earthquakes can now happen everywhere. The goal for a business should not be to resettle in a “safe” environment. Workers should learn to become organizational nomads: get used to the idea of packing your bags and relocating the whole organization to another business environment.

Which framework do we implement?

A framework for what? Do you want a predefined migration plan? Do you want a Gantt chart for turning a village into a caravan? I suggest you get people to figure out how to make vehicles from your tree houses and appoint some scouts who are willing to explore other environments. You can pick up books such as Out of the Forest, Escape Your Tree, and Business Nomads. They may speed up your learning. (You’re not the first to run from a fire.) You move your village by forcing everyone to accelerate their exploration and learning, not by arguing about the best framework for implementation of a plan.

How long will the transformation take?

Every time you ask a silly question, it takes one minute longer. How long does it take to get a group of people on the move? It depends on how many people you have, how willing they are to leave their homes behind them, how smart they are learning new skills, and whether the fire is still far enough so that you have some time to properly pack your bags. If you can see the fire, drop everything and run! Travel will be slower without preparations, but at least you’ll live. As a villager, you can estimate all these things better than I can, as a visiting traveler.

Should the transformation be bottom-up or top-down?

Is that in any way relevant? The fire is coming sideways! Everyone in the village will have to prepare for the move. Some will start earlier than others. Some will learn faster than others. And some will do more than others. Failed transformations are those where people waste time debating endlessly who should take the lead. The fire doesn’t care if the officials are leading the escape or not. Leaders are those whose bags are packed first and then show others how to do it. In an escape, there’s no bottom-up and top-down. There’s only inside-out.

How do we convince the managers?

Convince the managers of what? That there’s a fire coming? If they don’t smell it, I would start packing my bags without permission of the managers. But managers often know quite well that the village isn’t safe anymore. The usual problem is that they want to manage the migration the way they always managed the village. They want to apply the laws for tree houses also to mobile homes. But a band of travelers is different from a group of villagers and thus, they need different rules. Tell your managers that the road trip needs management with new rules.

Are OutOfTheForest and BusinessNomads just buzzwords?

Who cares? Smell the fire! Don’t just stand there discussing proper terminology. Start leading the escape!

Organizations change and survive when people accelerate their pace of exploration and learning. The way a company was managed in its old environment doesn’t work that well when it’s moving about, finding a new environment. And another one. And another one. Even worse, none of the same rules apply to the transformation itself. The migration, at least in the beginning, is all improvisation!

So, instead of your usual plans, targets, performance evaluations, committees, and policies, I suggest you hold a regular corporate huddle or town hall meeting and get everyone involved in updating each other on the status of the danger, the opportunities for safer places, and the progress of the travel preparations. Each person, from their own discipline, takes responsibility for learning how to be a valuable community member among the new business nomads.

That’s how you save your business.

photo: (c) 2006 Ervins Strauhmanis, Creative Commons 2.0

The post How to Save Your Business appeared first on NOOP.NL.

Categories: Project Management