Tag Archives: Software

Better code with inner source

I was a member of the Software track committee for GHC, which meant that by attending the conference in person, I was also responsible for chairing a session. Session chairs arrive in the room prior to the start of the presentation and ensure that the presenters have arrived, there are no technical difficulties with A/V equipment, the timer is set up and ready to go, and the session starts and ends on time. The session that I chaired was titled “Better Together: The Inner Source Journey.” Presenters Aliza Carpio and Rocio Montes shared the findings of Intuit’s case study detailing its lessons from embarking on an inner source journey.

By now, you’re probably asking yourself, “What is inner source?” In brief, it is leveraging open source software development practices within your organization. Having been on teams that develop with and without these software practices, I can personally attest to the value of institutionalizing them. Not everyone will want to adopt new ways of working, some will have to be dragged kicking and screaming. Every journey starts with a champion(s), Aliza and Rocio are those brave individuals in this story.

If you work for a company with a large number of developers aligned with different business units, who have competing priorities, and are dispersed geographically, you are painfully familiar with the silos this can create. The challenges Aliza outlined for Intuit were:

  • Code was owned (not stewarded) by teams and individuals, which led to bottlenecks and long wait times for code changes
  • The waiting impacted work/life balance and created a culture of heroics to meet deadlines
  • Repositories lacked documentation, or the documentation was only good enough to be used by the people who already owned the code
  • Varying standards made it difficult to on board new members

So how do you ensure people can work together across the globe and still produce quality software? Rocio discussed three simple criteria to start. Make sure that repositories are:

  • Discover-able – Can people find it?
  • Contribute-able – Once they have found it, can they incorporate their changes?
  • Compose-able – Are there processes in place to ensure that new changes are non breaking?

This means that people, process, and technology changes must be instituted.

Process:

  1. Make sure there is ONE set of unified guidelines, including
    1. A standard structure for repositories
    2. A minimum set of documents to detail contribution guidelines
    3. Rules of engagement — how do you engage the stewards of the repository?
    4. Templates for issues and pull requests that auto-populate with the expected information
  2. Use containers for local development — it minimizes the time to onboard new developers by fully encapsulating the working environment (packages, software versions, etc.)
  3. Continuous Integration/ Continuous Deployment (CICD) must be a part of the process
    1. Pull Request (PR) Builds give contributors and reviewers the opportunity to review tests and coverage to determine quality

People:

  1. See every PR as a mentorship opportunity!
  2. If it does not already exist, a “trusted committer” role, held by the group of developers who have the knowledge to do code reviews, and will be responsible for code mergers and reviewers , should be created
  3. Hold code review training to ensure that consistency and quality is maintained for each PR
  4. Make the trusted committer role a rotating on call so the burden is dispersed and not only one person is responsible — those who are frequent committers will eventually become trusted committers.
  5. Have service level agreements (SLAs) for PR reviews, merge and release; declare and define the timelines so external contributors know what to expect and can plan accordingly
  6. Scale efforts by identifying passionate advocates and leaders at each site (by location) to ensure there is someone physically present to champion the transition, and to assist with the technical implementation
  7. Identify repositories and teams that provide foundational capabilities to the organization, those that are a dependency for many other teams, and bring them to inner source first.
  8. Establish rewards and recognition — work with leaders to make the transition a part of each engineer’s goals

Technology:

While this was not explicitly mentioned during the session, I want to take the liberty of calling out the technology behind the inner source transition. These are observations based on the internal tools and processes in place at my company to support developers so that tooling does not become an encumbrance.

  • Secure the necessary support and funding to internally or externally host the tools to enable the inner source journey
  • Work with IT to identify the CICD pipeline, revision control, and ticketing systems you intend to use; make certain they are interoperable, and integrate them as an enterprise offering.
  • If Agile is part of your Software Development Lifecycle, add additional integrated tools to support the work methodology
  • Allow adoption of the tools to be independent — some teams may be more mature, so they can adopt the entire suite of tools, whereas others may need to start with just revision control.
  • Maintain training collateral for the suite of tools, but have a means of requesting assistance with on boarding
    • Regular office hours where people can dial in for live assistance
    • A means of submitting tickets or requesting help

Tools that I have used in this space are:

*Tool used by Intuit

Back to the session.

What steps do you have to take to start this journey at your company?

  1. Get support from leaders (Vice President, Director, Architect, etc.) and identify partnerships
    1. If possible make these connections in person
  2. Research and beautify the standards; the unified standards; guidelines, documentation, rules should be hosted in a repository as well so that they can be treated as code
  3. Identify teams who will be models for the transition to inner source and work with them to bring other teams along
  4. Conduct workshops to teach teams how to live in the culture

Preparing to be a champion

Moving to inner source is not just a technology adoption, it is a change management journey. To champion the transition, you will need to be able to articulate the return on investment and the business value. Aliza mentioned multiple resources to help prepare for making the case:

You must be a storyteller. Take the time to craft your message so you can be effective at being a catalyst for change!

Helping drive success

When people are new to inner source, it can be overwhelming. Intuit created a “good first issues” site that highlights filed issues from various repositories that are great introductory problems to solve for a newbie. Projects have their issues highlighted on the site by labeling their issues with the appropriate tags, and have well documented contribution guidelines. This also gives engineers an opportunity to gain new skills by working on new projects.

Creating a visible badge for taking the training, becoming a contributor, and championing inner source helps foster pride in the transition.

Creating pride in participation

The final result.

Intuit is one year into their journey and are already seeing the benefits. It is not enough to have anecdotal stories, you want to measure the value added by the transition to inner source, through measurement, analysis and presentation of the results.

Measure and analyze data

Now you’re ready to embark on your journey! Safe travels.

Smart Contracts using blockchain

One of the emerging trends in computing that everyone talks about, but can seldom articulate, is blockchain. What is that, you ask? If you’re like me, and haven’t done a deep dive, you’ve likely heard of it because of bitcoin, a cryptocurrency (digital money). I found a graphic that provides a nice high level description:

High level blockchain explaination

Where do people use blockchain? Anywhere you need to establish a trust relationship between applications to complete a transaction.

Now that we have a (fragile) foundation, we can dive into the GHC workshop I attended on Ethereum: A blockchain protocol with a complete built-in programming language. The workshop was presented by Julia Chou and Jenny Lu of Coinbase. Over the course of the workshop, we created a simple smart contract as a decentralized app (Dapp).

Prior to walking through the Dapp creation, Julia provided some context for the emergence of smart contracts and the use cases for blockchain.

Web 3.0: a peer to peer (decentralized) web, without servers or authorities to manage the flow of information, instead of the traditional client:server model, every client is also a server. This architecture avoids a single point of failure. In Web 3.0, browsers and wallets are able to represent identity and assets, allowing authentication and payment without using a bank or identity service. While this cuts out intermediaries for transfer of property, it leaves a gap in the establishment of trust (we trust lawyers and banks, we don’t trust unknown users with whom we’ve never interacted) — which is where the technologies we’ve discussed come into play: all processing is done via smart contracts using blockchain as the data storage and protocol.

Web 2.0 vs Web 3.0

Solidity was the language used in the workshop for developing the Ethereum smart contract. It is influenced by Javascript and C++. It is statically typed, compiled into Ethereum virtual machine bytecode, and is Object-Oriented. Ethereum is Turing complete, so a program could run infinitely — at great expense. To avoid this there is a concept called gas, tracked by ether (the Ethereum cryptocurrency), you can set a maximum amount of gas to expend, and if you run out, the program stops executing and rolls back the transaction. That is a very condensed description of a complex concept, so if you want to read more about gas, click here.

Now we can get into the workshop…

The workshop itself was intended to be completed over the course of an hour, and was targeted at (I believe) intermediate developers. The instructions are available here:https://github.com/jp3hou/dapp-demo, if you want to try it for yourself. The presenter slides are also available in the linked GitHub repository.

To complete the workshop, I will say that if you didn’t have Linux OS CLI (Ubuntu specifically), GitHub, and programming experience, you would have struggled to complete the exercise, there were a lot of assumptions. Before you start, you will need an Ubuntu OS or Windows 10 + WSL and Ubuntu, Chrome or other Metamask supported browser, and your IDE of choice; alternatively, you can use the online Solidity IDE .

The application we deployed was a simplification of the popular CryptoKitties. The core components:

And the underlying technology we used to create the Dapp:

I won’t take the time to walk through each step from the workshop, but would encourage you to follow the instructions from the GitHub Demo. Once you’ve completed the various steps to generate the test accounts, set up Metamask, and launch the Dapp, you can click on a kat to purchase it!

Successful kat purchase!

Security Concerns:

Hopefully you know a little more now than you did before. I certainly came away with my curiosity piqued!

Resources:

Hey, Google!

The second session I attended during GHC was a workshop entitled: Getting Started with Actions on Google. Presented by Surbhi Chaudhry, Mandy Chan, and Aylin Altiok, this workshop focused on teaching the key fundamental concepts when developing a conversational action for Google Assistant.

I own a Google Home Hub and find that this technology is particularly compelling because it is more than a convenience, it democratizes access to technology for those with physical and visual impairments.

During the workshop, Google had engineers with “I’m Here to Help” t-shirts, and it so happened that the engineer at my table did not have arms. It was not a point of conversation, but I noticed. I thought to myself, she must be very passionate about this technology — I wish I had asked about her journey, but I felt it might be inappropriate, so I didn’t.

A couple of key points that the presenters made about the different ways a user interacts with the assistant as opposed to a typical search are:

  1. Assistant queries are 200x more conversational than search
  2. Assistant queries are 40x more likely to be an action

Anecdotally, I know this to be the case because I like to ask my assistant to tell me jokes, sing me a song, and other queries that require it to exhibit more ‘human’ behavior than I would expect of my search engine. It’s gratifying to know that I am not the only one — there is data to back it up!

So let’s dig into the meat of the workshop. Over the course of the hour, we created a Google Action flow that allowed us to respond to a color query.

Google Actions workflow

You can walk through the exercise using just your browser and laptop, all of the resources are online. You’ll just need your Google account, a computer, and an internet connection.

It was great to have a working sample by the close of the workshop. The learning curve is not very high for completing a simple action query, and it is gratifying to have something working in a short period of time. If you want to play, it’s a good place to start. That being said, if you are a serious developer who is interested in implementing a more complex use case, we were strongly encouraged to start with understanding how best to design your actions. So, “Hey Developers, happy coding!”

(IoT) Mirror, Mirror on the wall

My Grace Hopper conference schedule this year was largely driven by my interest in learning as much as I can about all things Internet of Things (IoT), retail, and edge computing. Why? I’m glad you asked! I recently joined the Internet of Things Group (IOTG) as a Software Architect in Retail, Banking, Hospitality, and Education (RBHE) <– Intel loves acronyms. I wanted to take the opportunity to learn what emerging technologies can be applied in retail settings, and understand some of the challenges that are present. My background is data center and cloud infrastructure automation, so the retail space and managing a heterogeneous set of devices with varying network architecture requires a different, or at least modified, set of tools.

My first session was titled: Mirror, Mirror on the Dressing Room Wall, What Looks Good with This Dress? Presented by Allison Youngdahl and Sunil Shettigar, of Accenture, this presentation explored how brick-and-mortar stores can improve customer experience and give better data to retailers by leveraging IoT.

We have grown accustomed to a very individualized experience online, but in real life (IRL), walking into a retail location is one size fits all. E-commerce sites track our behavior, purchasing history, make recommendations, and often have free shipping and returns to seal the deal…but, once we receive the item in hand, we’re likely to return it nearly 80% of the time. Why? Just Google “online purchase fail,” and you’ll find pages of hilarious results:

Try before you buy. Even after carefully measuring, online purchase fails are rampant

We want to touch and feel an item, in fact, shoppers who try an item in a store are seven times more likely to purchase it, so the dressing room plays a vital role in sealing the deal. Fashion designer Rebecca Minkoff leveraged technology — interactive mirrors paired with RFID tags and a video wall, in her stores to drive triple digit sales growth. So what is the architecture behind such a successful solution? Allison and Sunil presented the solution Accenture Labs partnered with the Council of Fashion Designers of America (CFDA) to build.

The Retail Interactions Platform allows retailers to:

  • Understand the customer journey as they move through the store
  • Track total number of visitors in the store
  • Track item interaction from a clothing rack
  • Determine when an item is taken to a dressing room
  • Understand how item interaction leads to a purchase at the point of sale

Underlying technology:

  • Estimote Sticker Beacons (Bluetooth proximity sensors for physical objects)
  • Business Analytics – Calculate the product engagement score
  • Video analytics – heatmaps for traffic during peak hours
  • RFID Tags
  • MAC sniffers – Raspberry Pi with a WiFi adapter
  • Data visualization dashboard hosted on Google Cloud Platform
  • RESTful APIs

Product tracking was accomplished using RFID tags to “see” how the product moves through the store. Data streams from the various sensors were aggregated using Google Cloud. To track the number and frequency of visitors, the MAC sniffer identifies the MAC address of cell phones probes, which have a unique identifier, and quantify how long the individual was in the store as well as the frequency of visits. An engagement score was determined by capturing the XYZ coordinates of the product from the Estimote beacon (was it picked up and handled? For how long?); all of this is available in a dashboard.

Retail Interactions Platform Architecture
Visitor counting with data visualization

So how does this relate to mirrors?

Dressing room ambiance — temperature, lighting, music, can change how you feel about an item of clothing. Hate harsh, unflattering lighting that accentuates all of your flaws? So do I! So how can you make dressing rooms more hospitable places? Using the platform, you now have the product location, and with additional IoT devices in the dressing room, retailers can modify the environment, and also get immediate customer feedback on a product (new size needed? A different color?) to better serve you:

Mirror, Mirror in the dressing room, give me better lighting

The final take away was that retailers should focus on customer education, entertainment, and community. As much as an e-commerce site is convenient, it can never compete with a great experience IRL.