Archon volunteers at FoodShare

For many winter marks a time of celebrations and abundance, but some people do not have that luxury. Toronto’s FoodShare aims to make accessing healthy food possible and sustainable for everyone in our local community all year long through urban gardening projects, foodbox programs, school lunches, workshops, and more.

So on December 10th, we closed the Archon office and headed down to FoodShare to get our hands dirty by helping out in the community. We fostered team spirit amongst ourselves and also made connections with our fellow volunteers.
misc-300x300

We split up to divide and conquer two main tasks: kitchen prep and compost duties. As it turned out, the parents and pet owners among us seem to have volunteered for compost duty, or as Stephen keenly put it, “all the parents be like ‘poop is noooo problem.’”

Feeling like the seven dwarfs slinging compost with shovels, and hoping there’d be a lunch bell (so that we could sing “heigh-ho, heigh-ho!”), the compost team got to work digging. We measured the compost temperature, moisture, and shovelled it into new bins to turn and aerate it. We also sifted the finished compost and mulch, and watered plants.

compost-crew-300x300

Our team of kitchen ninjas peeled, sliced, and diced enough carrots and butternut squash to a) turn all of their hands a radioactive orange colour, and b) make 1000 cups of “Power Soup,” a program that donates soups to homeless shelters and Out of the Cold programs throughout Toronto.

Our kitchen crew reached celebrity status when our developer Brett was tweeted by FoodShare as saying “I’m no longer afraid of cutting butternut squash at home” and Matt, our marketing guru seemed to appear in an ad on the kitchen wall. (We have a theory that he farms in secret).

kitchen-crew-300x300

 

We were also put to work helping with holiday cards, moving furniture, and other odd jobs around the facility. When we told the volunteer supervisor that we were from a software company she teased “this is hardwork, not softwork!” Nevertheless, she was impressed with how much we finished that day.

All in all it was a fun day of spending time together while contributing to our community and a time for being grateful.

This article originally was posted on the inFlow Inventory Blog.

For many winter marks a time of celebrations and abundance, but some people do not have that luxury. Toronto’s FoodShare aims to make accessing healthy food possible and sustainable for everyone in our local community all year long through urban… Continue reading ‘Archon volunteers at FoodShare’

2 Comments

A sample mobile app and architecture for Xamarin (iOS, Android) using MvvmCross, ReactiveUI, and SQLite

Xamarin is a hot platform these days for writing cross-platform mobile applications in iOS, Android, and other platforms. You code in C# for all these platforms, which is great for us since we love C# and we can share code with our .NET desktop application, inFlow Inventory. We were evaluating Xamarin, so I started working on a sample application to try it out and look for an architecture which would let us share code cleanly. This post shares some of my experiences, thoughts, opinions, and code. The code is available here on github (please pardon the rough edges, it’s a prototype!).

The first big choice you make with Xamarin is do you want to build separate native UIs for each platform, or use Xamarin Forms to build one UI for all platforms. I found that the general sentiment is that Xamarin Forms can save you some effort if you’re planning on a very simple UI without too much customization for each platform, but for a more complex UI it’s better to build a separate UI for each platform. Since control over the UI/UX is important to our company, I chose the native UI route.

Given this choice, Xamarin lets you write pretty much any C# code, which means there’s no official framework for maximizing code-sharing across platforms. I’m a fan of the MVVM (Model-View-ViewModel) pattern, as I find it makes UI code easier to share and understand. I’m also a fan of Reactive Extensions, as I find that makes event-driven code much easier to work with (although there’s a substantial learning curve, since you have to learn to think in a new way). So I started by looking at ReactiveUI as a main framework, but quickly got frustrated by the scarcity of documentation and examples (or found that many of these were out of date) and the problems that I ran into.

I then looked into the MvvmCross framework, which seems to be used more heavily in the Xamarin community, and this generally worked pretty well. This provided a nice structure where I could set up ViewModels and data-bind them to the platform-specific interface code. For example, the shared ViewModel would have a property storing the value of a search query, as well as the logic of actually performing the search, and the platform-specific code would create the search UI control, and have some bindings so that when the user typed in a search query, that it be reflected in the ViewModel. Some other concepts like working with tables have special handling in iOS and Android, but these are pretty similar and straightforward to implement. Surprisingly, the logic for navigating between different screens can be handled in the shared code (by navigating to a ViewModel in the shared code, then each platform finding the view corresponding to that ViewModel).

I actually also ended up using pieces of ReactiveUI in a more limited capacity; this let me write the event-based code in a nice, reactive way, while using MvvmCross’s more mature data-bindings and navigation frameworks.

I did this prototyping on Windows using Visual Studio. Initially I tested it mostly on the Android platform, using the Xamarin Android Player simulator. This toolset works quite well, you can just hit Debug in Visual Studio and it updates the Android simulator and breakpoints work as you would expect. When working on the iOS platform, unfortunately Apple only allows compiling and testing iOS apps using a Mac, but Xamarin has come up with a way to use another Mac machine on the LAN as a build-server, so that you can hit Debug from Visual Studio, and it will run your program on the iOS simulator running on the Mac. My experience was that I felt it worked better than I expected, but was significantly buggier than the Android tools. For example, the debugger often wouldn’t work, and I ran into some problems with the iOS UI editors. You can also run the Xamarin Studio IDE directly on a Mac, which from a very brief trial was better than I expected, but not as good as Visual Studio.

Incidentally, iOS has a concept (supported in Xamarin) called storyboards that allows you to design multiple screens in one file, as well as the navigation and transitions between them (“segues”). I chose to have each storyboard only contain one view, for two reasons. First, I heard that when working with large storyboards in a team environment, source control merge conflicts can be a huge pain. Secondly, since Android doesn’t have a similar concept, having a one-to-one mapping of storyboards and views allowed me to keep the same paradigm across both platforms, thus sharing more code.

I also prototyped using local storage for the mobile apps in the form of a local SQLite database. The open source packages for SQLite worked flawlessly for me across both platforms, with only minimal platform-specific initialization code, and having shared code for dealing with a local SQL database was a big win.

As one indication of how well the code-sharing with Xamarin and this architecture works, when I updated the Android prototype to add the ability to sync with a copy of our desktop application, the same functionality worked immediately on iOS with no code changes at all required; all the changes took place in shared code and just-worked. (This syncing code was a dirty hack that I’m too embarrassed to share, however.)

Overall, I was very impressed with Xamarin; although I ran into some bugginess, it’s very impressive what they’ve pulled off. I think it’s probably the best way to develop mobile apps that need to target both Android and iOS today. The community has a lot of momentum behind it and is continuing to grow, with some help from Microsoft. It’s a lot of fun to be able to share C# code between desktop, Android, and iOS, and see changes from my physical phone propagate to my desktop.

I’ve mostly talked about this in feelings and generalities, but the code is available here, and I’d be happy to discuss specifics in the comments!

Interested in working with Xamarin? We’re hiring! You don’t necessarily need Xamarin experience already, but if you’re an expert, I’d love to hear all the things I did wrong!

Xamarin is a hot platform these days for writing cross-platform mobile applications in iOS, Android, and other platforms. You code in C# for all these platforms, which is great for us since we love C# and we can share code… Continue reading ‘A sample mobile app and architecture for Xamarin (iOS, Android) using MvvmCross, ReactiveUI, and SQLite’

3 Comments

A process for feature selection and release planning

We’ve got a strong team of developers working on inFlow Inventory, but we also have 231 feature requests right now, with more coming in all the time. What do we do?

Step one: take a deep breath. Step two: realize how incredibly lucky we are to have such a supportive community willing to help us improve. Step three: think long and hard about how best to meet their needs.

Obviously, we can only do so much at once, and some requests might make sense for one individual company but not for the community as a whole. So what do we work on first? Our starting point, naturally, is what does the inFlow community want us to work on? We talk with hundreds of customers a day through our customer support and social media, and we track every time we get a request for a feature or a problem to be solved.

We assign a vote score for each feature based on the number of customer requests recorded. Older votes are weighted less heavily than more recent votes; the logic here is that the needs of the community may shift over time, and if we’ve stopped hearing about something, it may be less important than it once was.

We also have our developers estimate how long it would take to implement each feature. Then, we sort the features by vote score divided by time estimate. The features with the highest ratio are generally the ones where we can help the most people the fastest.

We do, of course, leave room for human judgment. For example, some features may affect relatively less people, but be absolutely critical to them. Or certain related features may make sense to work on at the same time. So our entire team (most importantly the support team, who talk with customers the most) will discuss and vote on which features they think we should implement in the next release. Each person is given a budget (about 2 months worth of development work) and can vote for features within it. Based on this, we’ll discuss until we come to a consensus on the plan for the next release.

Sometimes we also schedule some work separately from this process, typically things that improve inFlow significantly but aren’t the sort of thing we’d get a lot of feedback about. For example, we recently invested in making the installation faster and more reliable, which we knew was important without being explicitly asked for this very often.

Depending on what surprises we come across as part of the development process, we might hold back a release to ensure that we get the details right, or sometimes we’ll even have time to do some extras besides what was originally planned.

We also handle software bugs separately. There’s no way for us to predict in advance what bugs will be discovered, but we try our best to take care of bugs as they come up, instead of letting them build up into a big hive. During the beta testing period, we focus on fixing bugs that were discovered, and then start the process over for the next release!

This process has helped us to preserve our much-needed sanity, and to serve the inFlow community’s needs while retaining responsibility for managing releases and the product as a whole. Keep that precious feedback coming, we can handle it!

We’ve got a strong team of developers working on inFlow Inventory, but we also have 231 feature requests right now, with more coming in all the time. What do we do? Step one: take a deep breath. Step two: realize… Continue reading ‘A process for feature selection and release planning’

2 Comments

Inventory.xlsx – the most powerful online inventory application

The keen-eyed among you may have noticed the “Secret Stealth Project” listed on our website.  Today, we are proud to announce the public release of Inventory.xlsx; a state-of-the-art, online inventory application.

Inventory.xlsx is the culmination of three years of dedicated research and development effort.  We took everything we’ve learned from our wildly successful first product, inFlow Inventory, and brought it to the world’s most popular spreadsheet program – Microsoft Excel.  Now, for the first time, the inventory tracking power of inFlow is available on both the Windows and Mac platforms.

With Inventory.xlsx, collaborating with colleagues couldn’t be easier.  Just make a change to the file, save it, and email it to your colleague.  We are able to leverage a system that everyone is comfortable with, email, to provide top-tier cloud collaboration power*.

We’ve even included an email :mailto link field to send out invoices directly from our application.  Just click on your customer’s email address, and an email will automatically be created in your favourite email software.  Making invoices for your customers is as simple as clicking a link, typing in their contact info, adding your items, formatting the header & footer, printing it out, and, finally, walking to your closest mailbox (the physical one).

Three years may seem like a long development cycle for an inventory application, but we encountered many challenges along the way.  For example, when we started, we were using the most popular spreadsheet format at the time – .xls.  But to deliver the most cutting edge technology, we added an “x” at the end.  Adopting the .xlsx extension places us at the vanguard of technology.

We’re really excited to get this in your hands.  Until March 33rd, we are making Inventory.xlsx application completely free to download.

Get your Inventory.xlsx for free today!

 

*Coming Soon: We aren’t done yet.  We’re busy porting Inventory.xlsx to Google Drive Spreadsheets.  When we’re done, we will unleash brand new ways for you to collaborate with your colleagues in real-time.  Stay tuned!

The keen-eyed among you may have noticed the “Secret Stealth Project” listed on our website.  Today, we are proud to announce the public release of Inventory.xlsx; a state-of-the-art, online inventory application. Inventory.xlsx is the culmination of three years of dedicated research… Continue reading ‘Inventory.xlsx – the most powerful online inventory application’

2 Comments

Group, fear, distance, and innovations.

In a recent interview, Google’s CEO, Larry Page, said “Most businesses fail because they miss the future.”

I can’t agree more.

However, I don’t think it is a failure to envision the future.  The problem, I think, is that often times there are invisible inertia which prevent companies from doing radically new things.  Incremental improvements are praised and encouraged.  But forward-leaping initiatives just don’t happen as often.

Why is that?

To examine it further, we have to look at how a group of people makes decisions.  In social science, the ideas of conformity, social norm, and groupthink have long been studied.  These powerful forces come into play during the decision making process, whether we know it or not.  Essentially, these forces boil down to fear.

Fear of being wrong.  Fear of sounding stupid.  Fear of push-backs.  Fear of rocking the boat.  Fear of sticking our neck out.

On the other hand, the distanced relationship between an individual and the decision outcome is usually not apparent.  It is hard for anyone to relate a group decision to their personal well-being.  After all, who thinks that agreeing with colleagues at work will have any significant impact on their lives?

When these two powerful forces: fear we all share and distanced responsibility, are combined, it only makes sense for any sane person not to risk themselves pushing for something different.  The inertia for change creates a barrier for leaping innovations.  Lack of true innovation ultimately brings demise to a business.

How do we fix that?

To address the fear problem, we need to create a safe environment where people feel comfortable voicing out their thoughts.  This means not passing judgement too early when an idea is still brewing.  This means encouraging people to speak up whenever they have concerns.  This means separating the individuals from the issues itself. (“It is not about you or me, it’s about the issue at hand”).

For the distance problem, communication and transparency is the key.  By communicating the impact of a decision and be totally transparent about its outcome – no matter success or failure, people can better relate the decision to its outcome.  By nature, no one wants their company to fail.  Once we realize the significance we have on the decisions we help making, we feel responsible for its success and failure.

By conquering our fear to conform and feeling responsible for the decisions outcome, we can bring about real innovations to the world – innovations that shape the future we all live in.

“What would you do if you weren’t afraid?”   – Mark Zuckerberg

In a recent interview, Google’s CEO, Larry Page, said “Most businesses fail because they miss the future.” I can’t agree more. However, I don’t think it is a failure to envision the future.  The problem, I think, is that often… Continue reading ‘Group, fear, distance, and innovations.’

Leave a comment