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!

Programming

Building, testing and deploying precompiled Azure Functions

Xebia Blog - Tue, 01/31/2017 - 16:00
Azure functions are great to build small specialized services really fast. When you create an Azure Functions project by using the built-in template from the SDK in Visual Studio you’ll automatically get a function made in a CSX file. This looks like plain old C# but in fact it is actually  is C# Script. When

Go: Multi-threaded writing to a CSV file

Mark Needham - Tue, 01/31/2017 - 06:57

As part of a Go script I’ve been working on I wanted to write to a CSV file from multiple Go routines, but realised that the built in CSV Writer isn’t thread safe.

My first attempt at writing to the CSV file looked like this:

package main


import (
	"encoding/csv"
	"os"
	"log"
	"strconv"
)

func main() {

	csvFile, err := os.Create("/tmp/foo.csv")
	if err != nil {
		log.Panic(err)
	}

	w := csv.NewWriter(csvFile)
	w.Write([]string{"id1","id2","id3"})

	count := 100
	done := make(chan bool, count)

	for i := 0; i < count; i++ {
		go func(i int) {
			w.Write([]string {strconv.Itoa(i), strconv.Itoa(i), strconv.Itoa(i)})
			done <- true
		}(i)
	}

	for i:=0; i < count; i++ {
		<- done
	}
	w.Flush()
}

This script should output the numbers from 0-99 three times on each line. Some rows in the file are written correctly, but as we can see below, some aren't:

40,40,40
37,37,37
38,38,38
18,18,39
^@,39,39
...
67,67,70,^@70,70
65,65,65
73,73,73
66,66,66
72,72,72
75,74,75,74,75
74
7779^@,79,77
...

One way that we can make our script safe is to use a mutex whenever we're calling any methods on the CSV writer. I wrote the following code to do this:

type CsvWriter struct {
	mutex *sync.Mutex
	csvWriter *csv.Writer
}

func NewCsvWriter(fileName string) (*CsvWriter, error) {
	csvFile, err := os.Create(fileName)
	if err != nil {
		return nil, err
	}
	w := csv.NewWriter(csvFile)
	return &CsvWriter{csvWriter:w, mutex: &sync.Mutex{}}, nil
}

func (w *CsvWriter) Write(row []string) {
	w.mutex.Lock()
	w.csvWriter.Write(row)
	w.mutex.Unlock()
}

func (w *CsvWriter) Flush() {
	w.mutex.Lock()
	w.csvWriter.Flush()
	w.mutex.Unlock()
}

We create a mutex when NewCsvWriter instantiates CsvWriter and then use it in the Write and Flush functions so that only one go routine at a time can access the underlying CsvWriter. We then tweak the initial script to call this class instead of calling CsvWriter directly:

func main() {
	w, err := NewCsvWriter("/tmp/foo-safe.csv")
	if err != nil {
		log.Panic(err)
	}

	w.Write([]string{"id1","id2","id3"})

	count := 100
	done := make(chan bool, count)

	for i := 0; i < count; i++ {
		go func(i int) {
			w.Write([]string {strconv.Itoa(i), strconv.Itoa(i), strconv.Itoa(i)})
			done <- true
		}(i)
	}

	for i:=0; i < count; i++ {
		<- done
	}
	w.Flush()
}

And now if we inspect the CSV file all lines have been written successfully:

...
25,25,25
13,13,13
29,29,29
32,32,32
26,26,26
30,30,30
27,27,27
31,31,31
28,28,28
34,34,34
35,35,35
33,33,33
37,37,37
36,36,36
...

That's all for now. If you have any suggestions for a better way to do this do let me know in the comments or on twitter - I'm @markhneedham

The post Go: Multi-threaded writing to a CSV file appeared first on Mark Needham.

Categories: Programming

Verbal Turn Indicators For Intercultural Product Owners

Xebia Blog - Mon, 01/30/2017 - 19:30
Jujutsu exams are coming up. One of the things that examiners want to see in jujutsu is the use of go-no-sen, sen-no-sen and tai-no-sen. Go-no-sen means that you respond to an action of your opponent, tai-no-sen means you act simultaneously and sen-no-sen means you take the initiative and act before the opponent has a chance.

A better way (and script) to add a Service Principal in Azure for VSTS

Xebia Blog - Mon, 01/30/2017 - 16:53
From Visual Studio Team Services (VSTS) it’s possible to deploy to an Azure Subscription using an Active Directory Service Principal. The Microsoft documentation refers to a blog post which describes a 3-clicks and a manual way to setup this principal. Although the information on the blog post for the 3-clicks setup is still actual, the script link

Running Powershell Pester unit test in a VSTS build pipeline

Xebia Blog - Mon, 01/30/2017 - 16:34
When you are developing Powershell scripts, creating some unit tests will help you in monitoring the quality of the scripts. Writing some tests will give you some assurance that your code still works after you make some changes. Writing Powershell unit tests can be done with Pester. Pester will enable you to test your Powershell scripts from

3 key ingredients that make you a better developer

Xebia Blog - Mon, 01/30/2017 - 10:21
IT is a booming business, but that doesn’t mean everyone who’s drawn to it will become a great developer. Many students sign up for an IT education for the wrong reasons. I've had classmates who enrolled in IT-related degree programs because they liked gaming or working with computers. Maybe they created a website for a

I'm Loyal to Nothing Except the Dream

Coding Horror - Jeff Atwood - Mon, 01/30/2017 - 10:19

There is much I take for granted in my life, and the normal functioning of American government is one of those things. In my 46 years, I've lived under nine different presidents. The first I remember is Carter. I've voted in every presidential election since 1992, but I do not consider myself a Democrat, or a Republican. I vote based on leadership – above all, leadership – and issues.

In my 14 years of blogging, I've never written a political blog post. I haven't needed to.

Until now.

It is quite clear something has become deeply unglued in the state of American politics.

As of 2017, the United States, through a sequence of highly improbable events, managed to elect an extremely controversial president.

A president with historically low approval ratings, elected on a platform many considered too extreme to even be taken literally:

Asked about Trump’s statements proposing the construction of a wall on the US-Mexico border and a ban on all Muslims entering the country, Thiel suggested that Trump supporters do not actually endorse those policies.

“I don’t support a religious test. I certainly don’t support the specific language that Trump has used in every instance,” he said. “But I think one thing that should be distinguished here is that the media is always taking Trump literally. It never takes him seriously, but it always takes him literally.”

The billionaire went on to define how he believes the average Trump supporter interprets the candidate’s statements. “I think a lot of voters who vote for Trump take Trump seriously but not literally, so when they hear things like the Muslim comment or the wall comment their question is not, ‘Are you going to build a wall like the Great Wall of China?’ or, you know, ‘How exactly are you going to enforce these tests?’ What they hear is we’re going to have a saner, more sensible immigration policy.”

A little over a week into the new presidency, it is obvious that Trump meant every word of what he said. He will build a US-Mexico wall. And he signed an executive order that literally, not figuratively, banned Muslims from entering the US — even if they held valid green cards.

As I said, I vote on policies, and as an American, I reject these two policies. Our Mexican neighbors are not an evil to be kept out with a wall, but an ally to be cherished. One of my favorite people is a Mexican immigrant. Mexican culture is ingrained deeply into America and we are all better for it. The history of America is the history of immigrants seeking religious freedom from persecution, finding a new life in the land of opportunity. Imagine the bravery it takes to leave everything behind, your relatives, your home, your whole life as you know it, to take your entire family on a five thousand mile journey to another country on nothing more than the promise of a dream. I've never done that, though my great-great grandparents did. Muslim immigrants are more American than I will ever be, and I am incredibly proud to have them here, as fellow Americans.

Help Keep Your School All American!

Trump is the first president in 40 years to refuse to release his tax returns in office. He has also refused to divest himself from his dizzying array of businesses across the globe, which present financial conflicts of interest. All of this, plus the hasty way he is ramrodding his campaign plans through on executive orders, with little or no forethought to how it would work – or if it would work at all – speaks to how negligent and dangerous Trump is as the leader of the free world. I want to reiterate that I don't care about party; I'd be absolutely over the moon with President Romney or President McCain, or any other rational form of leadership at this point.

It is unclear to me how we got where we are today. But echoes of this appeal to nationalism in Poland, and in Venezula, offer clues. We brought fact checkers to a culture war … and we lost. During the election campaign, I was strongly reminded of Frank Miller's 1986 Nuke story arc, which I read in Daredevil as a teenager — the seductive appeal of unbridled nationalism bleeding across the page in stark primary colors.

Daredevil issue 233, page excerpt

Nuke is a self-destructive form of America First nationalism that, for whatever reasons, won the presidency through dark subvocalized whispers, and is now playing out in horrifying policy form. But we are not now a different country; we remain the very same country that elected Reagan and Obama. We lead the free world. And we do it by taking the higher moral ground, choosing to do what is right before doing what is expedient.

I exercised my rights as a American citizen and I voted, yes. But I mostly ignored government beyond voting. I assumed that the wheels of American government would turn, and reasonable decisions would be made by reasonable people. Some I would agree with, others I would not agree with, but I could generally trust that the arc of American history inexorably bends toward justice, towards freedom, toward equality. Towards the things that make up the underlying American dream that this country is based on.

This is no longer the case.

I truly believe we are at an unprecedented time in American history, in uncharted territory. I have benefited from democracy passively, without trying at all, for 46 years. I now understand that the next four years is perhaps the most important time to be an activist in the United States since the civil rights movement. I am ready to do the work.

  • I have never once in my life called my representatives in congress. That will change. I will be calling and writing my representatives regularly, using tools like 5 Calls to do so.

  • I will strongly support, advocate for, and advertise any technical tools on web or smartphone that help Americans have their voices heard by their representatives, even if it takes faxing to do so. Build these tools. Make them amazing.

  • I am subscribing to support essential investigative journalism such as the New York Times, Los Angeles Times, and Washington Post.

  • I have set up large monthly donations to the ACLU which is doing critical work in fighting governmental abuse under the current regime.

  • I have set up monthly donations to independent journalism such as ProPublica and NPR.

  • I have set up monthly donations to agencies that fight for vulnerable groups, such as Planned Parenthood, Center for Reproductive Rights, Refugee Rights, NAACP, MALDEF, the Trevor Project, and so on.

  • I wish to see the formation of a third political party in the United States, led by those who are willing to speak truth to power like Evan McMullin. It is shameful how many elected representatives will not speak out. Those who do: trust me, we're watching and taking notes. And we will be bringing all our friends and audiences to bear to help you win.

  • I will be watching closely to see which representatives rubber-stamp harmful policies and appointees, and I will vote against them across the ticket, on every single ticket I can vote on.

  • I will actively support all efforts to make the National Popular Vote Interstate Compact happen, to reform the electoral college.

  • To the extent that my schedule allows, I will participate in protests to combat policies that I believe are harmful to Americans.

  • I am not quite at a place in my life where I'd consider running for office, but I will be, eventually. To the extent that any Stack Overflow user can be elected a moderator, I could be elected into office, locally, in the house, even the senate. Has anyone asked Joel Spolsky if he'd be willing to run for office? Because I'd be hard pressed to come up with someone I trust more than my old business partner Joel to do the right thing. I would vote for him so hard I'd break the damn voting machine.

I want to pay back this great country for everything it has done for me in my life, and carry the dream forward, not just selfishly for myself and my children, but for everyone's children, and our children's children. I do not mean the hollow promises of American nationalism

We would do well to renounce nationalism and all its symbols: its flags, its pledges of allegiance, its anthems, its insistence in song that God must single out America to be blessed.

Is not nationalism—that devotion to a flag, an anthem, a boundary so fierce it engenders mass murder—one of the great evils of our time, along with racism, along with religious hatred?

These ways of thinking—cultivated, nurtured, indoctrinated from childhood on— have been useful to those in power, and deadly for those out of power.

… but the enduring values of freedom, justice, and equality that this nation was founded on. I pledge my allegiance to the American dream, and the American people – not to the nation, never to the nation.

Daredevil issue 233, page excerpt

I apologize that it's taken me 46 years to wake up and realize that some things, like the American dream, aren't guaranteed. There will come a time where you have to stand up and fight for them, for democracy to work. I will.

Will you?

[advertisement] At Stack Overflow, we help developers learn, share, and grow. Whether you’re looking for your next dream job or looking to build out your team, we've got your back.
Categories: Programming

Understanding serverless cloud and clear

Xebia Blog - Sun, 01/29/2017 - 13:57
Serverless is considered the containers’ successor. But although it’s promoted heavily, it still isn’t the best fit for every use case. By knowing what its pitfalls and disadvantages are, it becomes quite easy to find the use cases which do fit the pattern. This post gives some technology perspectives on the maturity of serverless today.

De future fit organisatie - praktijkervaringen deel 1: De kracht en waarde van interne Agile Coaches

Xebia Blog - Fri, 01/27/2017 - 11:59
Een succesvolle transformatie naar een wendbare, future fit organisatie begint bij het neerzetten van de basis voor de borging. Een organisatie die start met heldere en begrijpelijke cultuurwaarden die het fundament vormen waarop de organisatie steunt. Niet alleen IT en/of Business los van elkaar maar samen met een gemeenschappelijke “purpose” gericht op (klant)waarde. De Agile

Let Operational Analytics improve your business

Xebia Blog - Fri, 01/27/2017 - 11:52
Products and services are getting smarter. The Google Car can drive itself. Your phone knows how to take the best selfie and it even tells you when to leave to be on time for that important meeting. The systems that run these services are able to use and understand data in a very smart way.

Use VSTS to deploy Functions as Infrastructure as Code

Xebia Blog - Fri, 01/27/2017 - 09:10
Azure Functions enable you to easily run small pieces of code in the cloud. To do this right, you need to setup continuous delivery of the infrastructure and the code involved. Otherwise you will end with an uncontrolled environment where nobody knows what code is actually running. In this blog post I’ll describe how to

Final Android Wear 2.0 Developer Preview: iOS support. Time to upload your apps to the Play Store!

Android Developers Blog - Thu, 01/26/2017 - 04:24
Posted by Hoi Lam, Developer Advocate 

Cross platform support by Telegram Messenger

Today, we are releasing the fifth and final developer preview for Android Wear 2.0. In this release, we have added iOS support and included a number of bug fixes and enhancements. Apps compiled with this preview are now ready for final submission to the Google Play Store, so it's time to publish your apps. As Android Wear 2.0 approaches its final release in early February, we would like to thank you for your continued feedback during the developer preview program. Your input has helped us uncover bugs as well as drive critical product decisions. Thank you!

iOS Support
Since 2015, you've been able to pair Android Wear watches with iPhones, and now you can distribute your apps to iPhone-paired watches as well. To do so, just set the standalone=true flag in your watch app manifest. This lets the Play Store know that your watch app doesn't require an Android phone app, and therefore can appear in the Play Store on watches paired to iPhones. To pair your watch to an iPhone and test, just follow these steps.

<application …>
   <meta-data android:name="com.google.android.wearable.standalone" android:value="true"/>
    …
</application>

The available network bandwidth for standalone apps can be lower than expected, as the platform balances battery savings vs network bandwidth. Make sure to check out these guidelines for accessing the network, including accessing Wi-Fi and cellular networks on watches paired with iPhones.

Also with this developer preview release, Android Wear apps running on watches paired with iOS devices will be able to perform phone hand-off flows such as OAuth and RemoteIntent for launching a web page on a paired iOS device.

Uploading Your App to the Google Play Store
The final developer preview includes an update to the Wearable Support Library. Apps compiled with API level 25 and this support library are considered ready for deployment in the Google Play Store. Please note that there are no updates to the preview watch image or emulator in this developer preview release.
Other Enhancement and Bug Fixes
  • Navigation Drawer: Flip a flag to toggle to the single-page, icon-only navigation drawer, which provides faster, more streamlined navigation to different views in your app.
  • NFC HCE support: NFC Host Card Emulation FEATURE_NFC_HOST_CARD_EMULATION is now supported.
  • ProGuard and Complication API: New ProGuard configuration means complication data container classes will no longer be obfuscated. This fixes a ClassNotFoundException when watch faces are trying to access data supplied by a complication data provider.

Countdown to Launch
Thank you for the fantastic level of feedback we have gotten from you as developers. Check out g.co/wearpreview for the latest builds and documentation, and be sure to publish your apps before the Android Wear 2.0 consumer launch in early February. As we work towards the consumer launch and beyond, please continue filing bugs or posting comments in our Android Wear Developers community. We can't wait to see your Android Wear 2.0 apps!
Categories: Programming

And now for something (not quite completely) different - Cognitive relativism in consultancy

Xebia Blog - Wed, 01/25/2017 - 12:40
Since joining the test automation unit of Xebia (June 2015), I have written some blog posts, all revolving around the topic of ..., well, ... test automation. However, there are a lot of other topics, across various domains, that have my interest and with regard of which I hold pretty strong, sometimes even passionate, views

Discover and celebrate the best local games at Indonesia Games Contest

Android Developers Blog - Wed, 01/25/2017 - 05:00

Posted by David Yin, Business Development Manager, Indonesia, Google Play.

It is a great time to be a mobile game developer on Android with the opportunity reaching more than a billion global users on Google Play. At the same time, developers in fast growing mobile markets like Indonesia have an additional opportunity in the form of a huge local audience that is hungry for local content. We have already seen thousands of Indonesian developers launch high quality, locally relevant games for this new audience, such as "Tahu Bulat" & "Tebak Gambar".

In our continuous quest to discover, nurture growth, and showcase the best games from Indonesia, we are really happy to announce Indonesia Games Contest. This contest celebrates the passion and great potential of local game developers, and provides an opportunity to raise awareness of your game with global and local industry experts, together with gamers, from across Indonesia. It's also a chance to showcase your creativity and win cool prizes.
Entering the contest

The contest is only open to developers based in Indonesia who have published a new game on Google Play after 1 January 2016. Make sure to visit our contest website for the full list of eligibility criteria and terms. A quick summary of the process is below:
  1. If you are eligible, submit your game by 19 March 2017.
  2. Entries will be reviewed by Google Play team and industry experts, and up to 15 finalists will be announced in early April 2017.
  3. The finalists will get to showcase their games at the final event in Jakarta on 26 April 2017.
  4. Winner and runners up will be announced at final event.
To get started

Visit our contest website to find out more about the contest and submit your game.
Terima Kasih!


How useful did you find this blogpost?                                                                                 
Categories: Programming

Never trust a passing test

Actively Lazy - Tue, 01/24/2017 - 23:23

One of the lessons when practising TDD is to never trust a passing test. If you haven’t seen the test fail, are you sure it can fail?

traffic-lights-208253_1920Red Green Refactor

Getting used to the red-green-refactor cycle can be difficult. It’s very natural for a developer new to TDD to immediately jump into writing the production code. Even if you’ve written the test first, the natural instinct is to keep typing until the production code is finished, too. But running the test is vital: if you don’t see the test fail, how do you know the test is valid? If you only see it pass, is it passing because of your changes or for some other reason?

For example, maybe the test itself is not correct. A mistake in the test setup could mean we’re actually exercising a different branch, one that has already been implemented. In this case, the test would already pass without writing new code. Only by running the test and seeing it unexpectedly pass, can we know the test itself is wrong.

Or alternatively there could be an error in the assertions. Ever written assertTrue() instead of assertFalse() by mistake? These kind of logic errors in tests are very easy to make and the easiest way to defend against them is to ensure the test fails before you try and make it pass.

Failing for the Right Reason

It’s not enough to see a test fail. This is another common beginner mistake with TDD: run the test, see a red bar, jump into writing production code. But is the test failing for the right reason? Or is the test failing because there’s an error in the test setup? For example, a NullReferenceException may not be a valid failure – it may suggest that you need to enhance the test setup, maybe there’s a missing collaborator. However, if you currently have a function returning null and your intention with this increment is to not return null, then maybe a NullReferenceException is a perfectly valid failure.

This is why determining whether a test is failing for the right reason can be hard: it depends on the production code change you’re intending to make. This depends not only on knowledge of the code but also the experience of doing TDD to have an instinct for the type of change you’re intending to make with each cycle.

When Good Tests Go Bad

A tragically common occurrence is that we see the test fail, we write the production code, the test still fails. We’re pretty sure the production code is right. But we were pretty sure the test was right, too. Eventually we realise the test was wrong. What to do now? The obvious thing is to go fix the test. Woohoo! A green bar. Commit. Push.

But wait, did we just trust a passing test? After changing the test, we never actually saw the test fail. At this point, it’s vital to undo your production code changes and re-run the test. Either git stash them or comment them out. Make sure you run the modified test against the unmodified production code: that way you know the test can fail. If the test still passes, your test is still wrong.

TDD done well is a highly disciplined process. This can be hard for developers just learning it to appreciate. You’ll only internalise these steps once you’ve seen why they are vital (and not just read about it on the internets). And only by regularly practising TDD will this discipline become second nature.


Categories: Programming, Testing & QA

SE-Radio Episode 280: Gerald Weinberg on Bugs Errors and Software Quality

Marcus Blankenship talks with Gerald Weinberg about software errors, the fallacy of perfection, how languages and process can reduce errors, and the attitude great programmers have about their work.  Gerald’s new book, Errors: Bugs, Boo-boos, and Blunders, focuses on why programmers make errors, how teams can improve their software, and how management should think of […]
Categories: Programming

SE-Radio Episode 280: Gerald Weinberg on Bugs Errors and Software Quality

Marcus Blankenship talks with Gerald Weinberg about software errors, the fallacy of perfection, how languages and process can reduce errors, and the attitude great programmers have about their work.  Gerald’s new book, Errors: Bugs, Boo-boos, and Blunders, focuses on why programmers make errors, how teams can improve their software, and how management should think of […]
Categories: Programming

Don't use ReactiveUI

Eric.Weblog() - Eric Sink - Tue, 01/24/2017 - 19:00
TL;DR

This blog post says the opposite of its lazy and deliberately provocative title. I have become a huge fan of ReactiveUI. I just want to ramble about the path I took to get here.

Listening to Paul Betts

I first heard about ReactiveUI at a conference presentation by Paul Betts. I think it was at Xamarin Evolve. Mostly I remember feeling dumb. He said a lot of things that I didn't understand.

I went to that session without much real experience in Model-View-ViewModel (MVVM) development. Conceptually, I understood the idea of a ViewModel. But Paul mostly talked about how ReactiveUI avoids certain problems. And since I had not experienced those problems, his words didn't sink in.

Talking to teenagers about risk

Each time one of my kids was approaching adolescence, I sat down and explained the risks associated with certain choices. Laws and moral judgements aside, the simple fact is that many choices involve risks, and I thought it would be helpful to pass along that bit of information.

And in each case, my child said, "Thanks Dad", and proceeded to always make wise and low-risk choices from that point on.

Well, actually, no.

Teenagers simply do not learn that way. They process risk very differently from people who are more mature. Tell a 16-year-old that "if you drive too fast you might get a ticket". The adolescent will immediately begin driving too fast, and, in all likelihood, will not get ticket. This is how teenagers realize they are smarter than their parents.

Tangent #1: It is almost certainly a good thing that young people are more brave. It would be Very Bad if everybody started out with the same level of risk aversion as the average 65-year-old. Go watch the "Tapestry" episode of Star Trek TNG.

Tangent #2: I really should claim no expertise in parenting, but if somebody forced me to write a book on parenting a teenager, I would say this: Let your kid suffer from their own choices. That said, it is worth the effort to try and help them avoid the really bad mistakes, the ones with consequences that last for decades. But they do have to learn to make their own choices. Realize this as early as you can. The path to frustration starts with making everything all about you.

How we learn new technologies

My metaphor has many problems. For starters, Paul Betts is not my Dad.

Also, the element of adolescent rebellion was not present. I didn't hear Paul's wisdom and run in the opposite direction because of my deep need to separate my identity from his. In fact, I started devouring everything I could find on MVVM and IObservable. I really wanted to understand what he was saying.

But the metaphor works in one significant way: Like a teenager, I had to learn by doing. Nobody's words made much of a difference. None of that reading helped me become a a user of ReactiveUI. I went down another path.

Actually, I went down several other paths.

Maybe it's just me

I observe that most developers want content that explains how to get something done. "If your objective is to do X, then do the following steps." The most popular books and articles tend to follow this pattern. Questions of this form are the ones that do well on StackOverflow.

But this is almost never what I want.

I much prefer content that explains how things work. Once I understand that, I can figure out the steps myself.

When I am developing software, I always, ALWAYS do better when I understand what is going on "under hood", when I can see through the leaky abstractions.

And as I mentioned, I am apparently in the very small minority on this. If 90% of the world disagrees with me, does that put me in the top 10% ? Or does it mean my approach is somehow defective? Modesty aside, my history contains enough successes to allow me some confidence in believing that my approach is better.

I also observe that my approach is just a different spelling for the old adage, "Give a man a fish and you feed him for a day. Teach a man to fish and he eats for a lifetime."

If you tell a software developer what to type and where to click, you can help them complete today's task. But if you instead teach them how things work, they will be able to apply that understanding on other days too.

Hmmm. I'm talking myself into this. I don't know why most people prefer shallow recipes, but I really do think deep understanding is better.

Still, I like to stay open-minded about things. I've got a lot of failures too.

The truth is that my approach has tradeoffs. The need to understand everything tends to slow me down during the early stages. I usually gain some of that back in the fourth quarter of the game, where deeper understanding is often helpful in diagnosing tricky problems.

But again, in the decision making around software development, absolutes are rare. I'll admit that sometimes a simple set of steps without depth are exactly what is needed.

Maybe the ReactiveUI docs are just bad?

I don't know. Maybe. I've read the docs plenty. They don't seem bad to me. I also see nothing there that makes me want to defend them as the best docs ever.

Suppose that I regret not choosing ReactiveUI sooner. Further suppose that I wanted to blame somebody else for my choices. I guess I could find something to complain about. But I also don't tend to find that criticizing somebody else's work is helpful.

And remember, I started this journey sitting in front of an audience, listening to Paul Betts, and feeling dumb. To be clear, in that kind of context, I *like* feeling dumb. It's an opporunity to learn.

So why did I not choose ReactiveUI sooner?

I guess I don't really know. But I'm pretty sure that nothing has made me appreciate ReactiveUI more than the suffering that comes from not using it.

And that remark isn't very helpful, is it? I'd like to try and do better. Let's see...

"Son, it's just basic statistics. If you're going to always drive 15 MPH over the speed limit, you will eventually get caught. Suppose you roll the dice 20 times in a row without getting a 12. You still might get a 12 on the next roll, right?"

Oh, wait, wrong topic. Let me try again.

Why is ReactiveUI awesome?

In some software development situations, like mobile apps, if you take a step back and look at the forest instead of the trees, you will see that most of your code is reacting to something that changed.

There are lots of tools you can use to approach this kind of app. You can use C# events and callbacks and switch statements and delegates and lambdas and observables and notifications and bindings and more.

For simple apps, none of these approaches are much better than any other. But as your app gets more complicated, some approaches cope more gracefully than others.

Most cars drive pretty smooth at 30 MPH. But at 75 MPH, some vehicles are still giving a smooth ride, while others are shaking.

Let's try a conceptual example or two. Suppose you have a button, and you want something to happen when the user presses that button. This is pretty simple. All reasonable solutions to this problem are about the same.

On the other hand, let's say you have a list of items. The items in that list come from a SQL query. That query has 4 inputs, each of which comes from a UI control. Every time one of those controls changes its value, the query needs to be re-run and the list needs to be updated. A couple of those controls need to be disabled under certain circumstances.

These UI elements have a complicated relationship. We still have plenty of choices in how to express that relationship in code, but this situation is complicated enough that we start to see differences between those approaches. Some of the ones that worked out really well in the simple case seem kinda tedious for this case.

If my driveway has half an inch of snow, all methods of clearing it are about the same. But if my driveway has 15 inches of snow, a shovel is decidedly inferior to a tractor.

Why do I like ReactiveUI? Because I have found that it copes gracefully as the situation gets more complicated.

Why is this? Much of the credit goes to the "reactive" foundation on which ReactiveUI is built. Reactive Extensions. Rx. IObservable. These building blocks are particularly adept at expressing the relationship between a group of things that are changing. ReactiveUI adds another layer (or two) on top of these things to make that expressiveness more convenient when implementing user interfaces.

To be honest, I fudged a little bit when I said that all solutions are roughly equivalent when the problem is simple. That's not quite true. For simple situations, I'd have to admit that ReactiveUI might be a little worse. There is a learning curve.

If I am writing a grocery list, I could use a word processor, but a pencil and paper is actually simpler. But if I am writing a novel, the word processor is the clear winner.

I'm claiming that the effort to learn Rx and ReactiveUI is worth the trouble. My claim is based on this notion that ReactiveUI shines as complexity increases, but also on my belief that most people underestimate the complexity of their app.

If you disagreed with me above when I said that "most of your code is reacting to something that changed", you might be underestimating the complexity of your app. It is in fact very common to start implementing under the assumption that something will not change and then later realize that you need notifications or events. Or an observable.

Hmmmm.

Would the paragraphs above have changed my course earlier?

I don't know. Probably not.

I didn't start this believing that I could write the best ReactiveUI advocacy ever. Looking at it now, I can't believe I wrote it with no code in it. The canonical ReactiveUI evangelism pamphlet has gotta have WhenAnyValue() in it somewhere.

I just think it's interesting that despite my best efforts, I was unable to really understand the benefits of ReactiveUI until I tried using its alternatives. My current project is late. If I had chosen ReactiveUI earlier, maybe it would be, er, less late? There are questions here worth asking.

But am I 100% certain that it is always better to spare yourself the learning experience of using less effective approaches? No.

Can I credibly claim that everyone should choose ReactiveUI in every situation? Certainly not.

Maybe all I can say is that I am currently having a great experience with ReactiveUI.

Maybe that means the rest of this blog post is useless.

But you should have known that when you saw the cheesy title.

 

Android Instant Apps starts initial live testing

Android Developers Blog - Mon, 01/23/2017 - 19:48
Posted by Aurash Mahbod, Software Engineer, Google Play

Android Instant Apps was previewed at Google I/O last year as a new way to run Android apps without requiring installation. Instant Apps is an important part of our effort to help users discover and run apps with minimal friction.

We’ve been working with a small number of developers to refine the user and developer experiences. Today, a few of these Instant Apps will be available to Android users for the first time in a limited test, including apps from BuzzFeed, Wish, Periscope, and Viki. By collecting user feedback and iterating on the product, we’ll be able to expand the experience to more apps and more users.
To develop an instant app, you’ll need to update your existing Android app to take advantage of Instant Apps functionality and then modularize your app so part of it can be downloaded and run on-the-fly. You’ll use the same Android APIs and Android Studio project. Today, you can also take some important steps to be ready for Instant Apps development. The full SDK will be available in the coming months.

There has already been a tremendous amount of interest in Instant Apps from thousands of developers. We can’t wait to hear your feedback and share more awesome experiences later this year. Stay tuned!

Categories: Programming

Seeking a New Host for SE Radio

We have an opening for a volunteer host to produce five episodes per year. Please contact the show editor Robert Blumen for details.
Categories: Programming