This week I had the pleasure of giving two new talks at ConFoo 2026 in Montreal, Canada. For those who don’t know, I’ve spoken at ConFoo multiple times before — though it’s been six years since I last took the stage. The more astute among you will note that was just before everything shut down. Over the last six years I’ve been excited to see where our industry has evolved, and I hope to impart some knowledge every so often to those who attend my talks.

Here are the two talks I gave and amazingly enough neither one had even the hint of AI or LLMs. I’m therefore hugely grateful for those who chose to spend time with me and listen to the “war stories” on building aviation software.

1st Talk

Offline-First at 35,000 Feet: When Your App Can’t Call Home

Abstract

Most offline-first apps assume you’ll reconnect in minutes. What happens when your systems operate for hours without connectivity and no team to monitor them?

Real lessons from building systems that must work reliably in environments where network access is unreliable and remote debugging is impossible. We’ll explore data sync strategies, conflict resolution patterns, and building bulletproof systems when remote support isn’t an option.

2nd Talk

Spring Boot and GraalVM: Lessons from 35,000 Feet

Abstract

What do you do when your Spring Boot app suddenly needs 75% less memory? Here’s our real-world GraalVM retrofit story.

Actual production performance metrics, reflection gotchas that break compilation, brutal build times that killed productivity, and what we’d architect differently from day one to avoid the retrofit pain entirely.

The slides are now available and can be seen at the linked URLs above and also at our new Talks landing page.

Throughout the 3-day event I was able to attend several talks and see where the industry is focusing. It’s no surprise to see that 75% or more of the talks are centered on large language models and the greater AI landscape. If you spend any time on Twitter (I still refuse to call it anything else), you may be swayed by a belief that a 12-year old with a laptop and tokens in his piggy bank can replace you now. When you look at who’s pushing this belief, it’s usually someone selling an agentic solution, someone financially tied to a frontier model, or someone who hasn’t yet seen what software engineers actually do.

I was on a panel in 2019 in Sofia and the topic centered around AI. One of the questions from the audience was a plea to the panelists to find out if AI would soon take their job. Most of the panelists gave well-meaning answers and were likely correct for the time. My response:

“If an AI can do your job, is it enriching enough of a daily activity for you to continue?”

I believe this even more today. What we’ve been experiencing is not an extinction-level event for software engineering but a democratization. This technology has released more ideas into the wild and enabled an entirely new cohort of builders. I’ve been coding professionally for three decades, so maybe I’m an old dog — but one-shotting a todo app, a CRM, or a replacement for that SaaS you’ve been paying $19/mo for doesn’t strike fear in me. The calculus is way off. These builds haven’t accounted for real architecture and design, feature development, data storage, security, privacy, and the ongoing cost of maintenance.

The tools we have access to when used well can not only bring in an entirely new pool of original ideas but also free up seasoned engineers to explore new areas and get curious about technology outside their usual domain. We would also be wise to level up our junior engineers and keep that learning and gaining experience continually. When I’m evaluating talent, I’m not counting features. I want to know that you understand what you built and how it solved a real problem for a real customer. We will see more layoffs as executives attempt to show increased revenue by decreasing labor before realizing that those who understood how DNS worked were worth every penny. Our elders are as important as our juniors in this industry and we’d be wise not to lobotomize nor hollow out the middle in our quest for “efficiency”.

Our industry has a cyclical way of proclaiming the end of the software engineer1. The last year has only proven how much more we will depend on talent in this area. In many of the talks the question of who’s using agentic coding tools went up and the majority of the room had hands raised. The question I have for you is however much or little you’re using it, do you understand what you’re committing? Look at the commit log:

% git log
commit ea7e4fd3d4f7af8825818d822590fe78d60147a8 (HEAD -> main, origin/main)
Author: Andrew Lombardi <a*@***.com>

Look closely. My name is on this. That mantra should be the rally cry to ensure you aren’t adding slop. I wouldn’t accept an excuse of “Claude Code wrote this”, it’s yours.

• When the system gets hacked they won’t blame the agent, they’ll blame you.

• When the edge case gets tripped and your vibed code has leaked customer data, they’ll blame you.

• When the 3AM page happens and you’re on-call the team needs your brain.

So stay curious and engaged. Read your commits and PRs before you ask for the review because nothing sucks worse than reviewing bloated and wrong code that the asking developer can’t explain.

Remember, your name is on this.

On a lark I started asking an LLM about quantum entanglement. And when it spit out "an answer" it was a little tough to follow (of course). So I asked it to give me some analogies that might be more relatable. Here are some of what it came up with:

The Internet/Network Analogy

• Think of quantum entanglement like network packets with shared session IDs:

• When you change something on one server, all servers with that session ID instantly "know" about it

• The "threads" are like persistent TCP connections that maintain state across the network

• Gravity emerges like how network topology creates the "shortest paths" between nodes

There were others, and one of them talked about a Video Game Physics Engine which had invisible links and when one object moved, the other responded regardless of distance and gravity in the game world was just an emergent behavior. It then talked about force and information propagation which I "understand" is not possible given that information transmission is still gated by the speed of light.

A very odd relationship has emerged where YouTube will show me more and more videos about quantum mechanics, the Jinn particle, Schrödinger's poor dead/alive cat and at each time I pop over to an LLM to get a more thorough explanation. Each time now, because of my initial analogy request and the memory RAG, it gives me usually what amounts to an increasingly odd software engineering analogy. The most hilarious one so far is when I asked if you could send messages faster than the speed of light it gave me all the reasons why it couldn't, and then said "Think of the speed of light like a fundamental database constraint"

--- This is built into the universe's "database engine"

ALTER TABLE spacetime
ADD CONSTRAINT causality_limit
CHECK (information_speed <= speed_of_light);

-- You can have correlations (like foreign keys)
-- But actual data transfer hits the constraint

Now if Einstein or Bohr had the analogy engine here, maybe we'd be boarding a different imagination train. Through some of these analogies though, as mixed up as sometimes they appear to be, I think I've got a bit of a better understanding of some of these concepts. These analogies help me map a familiar pattern with an unfamiliar concept.

When I am explaining concepts in client meetings or with colleagues I will try to reach for an analogy if I can cook one up. If I'm explaining load testing I may mention it like a restaurant during a lunch rush since it equates well in a business setting. How many customers can we serve with the building and staff that we have? When explaining architecture or difficult concepts about how an integration will work it reduces the cognitive load and brings everyone up to speed quicker than a dry technical description. One thing I think we can always work on is having a wider variety of analogies to choose from.

Sometimes in a meeting or an unfamiliar setting an analogy can fall flat. That is totally OK! We can often learn what works best in these settings and steer the discussion toward the highway to understanding we're all shooting for. I have tested this in person meetings with a dozen people and in conference halls of up to 500+ people in cities outside my country of origin giving lectures on technology. It is very rare that I don't reach for multiple analogies in any of these situations as it is relatable, and connects us all.

The last bits that I had been researching in my context window that originally started with "proper methods of validating Pydantic enums" involved the concept of superposition. My understanding is that it relates to the thought experiment that Schrödinger was attempting when discussing this poor cat. I've always understood that the act of opening the box and observing the cat is what collapses the superposition into a single state.

Now comes Hugh Everett in the 50s with the Many Worlds Interpretation. Instead of this "mystical" collapsing of a superposition once a thing is observed and ending the story there, he theorized that all possible outcomes may actually happen and there is countless other universes where it occurs in all states. My brain hurts. So tonight I attempted to take the analogies, and the feeble amount of understanding I had gained from research and pull my family into explanations about all I had learned. In each of the humans I hold very dear, as I kept explaining I saw their mind there and not there at the same time. The many worlds interpretation in action!

Now I have ventured back to the computer to get a little work done. Maybe in one of these many worlds this code review includes tests.

Throughout my career as an architect and engineer of various systems over the last 30 years I've had a ton of ideas. My consulting company Mystic which has been in full effect for 25 years now was the hatching of an idea to bring along the best people in various disciplines I've run into and deploy them with me to help bring solutions to companies around the world. We've been able to solve problems for a lot of companies over the years such as Twitter 1.0, Motorola and Airbus to name a few. In each of these instances we've found our ultimate success by taking the seed of an idea on how to solve it and taking it the steps required to execute successfully.

If you read enough books on entrepreneurship and business, or listen to interviews with successful founders it becomes evident that what sets apart a successful endeavor is great execution, and a bit of luck. At no time was the idea the most important factor of the success.

• Instagram was a location-based check-in app like Foursquare -- remember that app?

• Slack was an internal comms tool for a gaming company (oddly enough Flickr was also an online game that pivoted to photo sharing)

• YouTube was a video dating site where people could upload videos describing their ideal date

These 3 examples should be enough proof that what mattered here was execution.

Enter AI and "agentic" coding.

I have seen a big trend online where "founders" or perhaps "marketers" are trying to convince you of something.

• Ideas are now gold!

• Taste is what matters in this new economy!

Whether it's a VC talking about engineers who code with AI and write 10k lines of code a day, or a course seller on "how to effectively prompt engineer your way to a million dollar app!". When it sounds like someone is trying to sell you a scheme, or convince you of something to further their own agenda, it's probably just that.

Since the beginning of the internet boom in the 90s the cost of turning your ideas into a reality meant hiring at a minimum designers and engineers to get a prototype together. The friction turned many away whether due to not having capital or not being able to convince a VC to fund it. With AI the friction according to those that are peddling that "ideas and taste" are all you need is effectively gone! The truth is a bit more nuanced than that.

At various times throughout my career I've been hearing how no-code solutions were going to kill software development for good and enable business owners to turn their ideas into reality. Whether it was Visual Basic or HyperCard in the desktop era, Dreamweaver or Flash in Web 1.0 or something as low level as BizTalk which promised to connect disparate systems together with ease, the reality was often barely functional or underlying it all extremely complex.

It might seem to some like the solutions out there with AI means we may finally be there. I know for me, the first time I used Claude Code to create an admin dashboard for a project, I was awestruck. It looked amazing. It was akin to hiring a few junior frontend engineers and having them build something that looked great after a few minutes of conversation.

And then I looked at the code it wrote.

The code was being held together by duct tape and chicken wire. What followed was countless hours of prompts and tinkering with the context to approach something passable. It didn't require vibes but much more expressive requirements, more guard rails and a set of instructions on acceptable code quality and standards. It often feels like it's performing magic but ends up more like an apprentice who sometimes turns your code into a goat. One of the most beautiful things to emerge from this process was that I have tightened up how I explain things in requirements and I ask better questions.

Building an app with an LLM is like someone who can't even boil water watching a cooking show demonstration and thinking they can run a restaurant. The real work lies in the edge cases and the day to day: suppliers, staff and health inspectors. It's no different with software. For this dashboard, It took engineering effort and a lot of time to turn the prototype that was built and bring together the knowledge and execution necessary to build a great application.

Large language models in software development is another tool in a software engineers toolbox that can be used toward creating a great product. It can be a great way to leverage the giant body of knowledge that it has to your own ends. It doesn't write perfect code, and it sometimes doesn't even produce working code! It will sometimes delete your code when it encounters an error with a new feature (git commit is your friend). It will ask you for every new session if it's allowed to do something until you learn how to configure the guard rails.

It is the junior engineer who seemingly knows everything and is confident they do, and often times gets it apologetically very wrong. It took me thirty years of experience to tell the difference.

So how can you leverage AI in your organization today?

1. Work together with your team to set up initial context and memory for your individual project and your organization.

2. Code review is now where a lot of care is needed. Your engineers are going to use AI to write code, care should be taken to make sure they know what it did and if it is fulfilling the requirements and user stories effectively.

3. Nurture the junior developers on the team so they can level up their skills and recognize good clean code when they see it.

4. Enable your business folks and product managers to build out prototypes to their hearts desires, and then bring these to engineers to find out what feasibility actually looks like.

The future has always been so very fun and interesting. Those that are telling you that AI will democratize execution are stuck in a hype cycle that hasn't explored why good execution is the key differentiator between a neat looking tasteful app and a thriving business.

If you'd like to engage with the team and find out how we can help you with your next project. Reach out to us today.

We are excited to announce the belated release of Beginning Spring AI. The book is intended to be a first look at using the Spring AI library to leverage the world of AI that is upon us. It is fascinating how fast the technology and releases of new models and new features.

Buy the book on Amazon on use coupon code DISCOVER20 to get 20% off the book through October!

It looks like we unfortunately missed the impending 1.0.0.GA by a few months! The code and examples written in the book were based on 1.0.0.M2 which feels like a lifetime ago. Last week Mark Pollack announced the Spring AI 1.0.0 RC1 release and that today will be the release of the GA! Super excited to see all the updates available and want to help with understanding how things have changed since the books release.

The most visible change is the complete overhaul of artifact IDs and package structure.

Artifact ID

<!-- OLD -->
<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
</dependency>

<!-- NEW -->
<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>

The pattern has changed to:

• Model starters: spring-ai-{model}-spring-boot-starter → spring-ai-starter-model-{model}

• Vector Store starters: spring-ai-{store}-store-spring-boot-starter → spring-ai-starter-vector-store-{store}

Package Name

Key classes have moved to new packages:

• KeywordMetadataEnricher and SummaryMetadataEnricher moved from org.springframework.ai.transformer to org.springframework.ai.chat.transformer

• Content, MediaContent, and Media moved from org.springframework.ai.model to org.springframework.ai.content

Module Structure

Spring AI now uses a modular architecture instead of a monolithic design:

• spring-ai-commons: Base module with no dependencies

• spring-ai-model: Core AI capability abstractions

• spring-ai-vector-store: Unified vector database abstraction

• spring-ai-client-chat: High-level conversational AI APIs

• spring-ai-advisors-vector-store: Bridges chat with vector stores for RAG

Chat Memory and Advisor

// OLD
// Using constants from AbstractChatMemoryAdvisor
myConfig.put(AbstractChatMemoryAdvisor.CHAT_MEMORY_CONVERSATION_ID_KEY, "conv123");

// NEW
// Now use constants from ChatMemory interface
myConfig.put(ChatMemory.CONVERSATION_ID, "conv123");

• CHAT_MEMORY_RETRIEVE_SIZE_KEY renamed to TOP_K

• DEFAULT_CHAT_MEMORY_RESPONSE_SIZE (value: 100) renamed to DEFAULT_TOP_K with a new default value of 20

• CHAT_MEMORY_CONVERSATION_ID_KEY moved from AbstractChatMemoryAdvisor to the ChatMemory interface

Tool Calling

// OLD (deprecated)
ChatClient chatClient = new OpenAiChatClient(api)
    .tools(List.of(new Tool("get_weather", "Get weather", params)))
    .toolCallbacks(List.of(new ToolCallback("get_weather", handler)));

// NEW
ChatClient chatClient = new OpenAiChatClient(api)
    .toolSpecifications(List.of(new Tool("get_weather", "Get weather", params)))
    .toolCallbacks(List.of(new ToolCallback("get_weather", handler)));

• The tools() method is now toolSpecifications()

• ToolContext is now final and cannot be extended

• ToolContext behavior changed to support both explicit and implicit tool resolution

Observability

Spring AI now uses logging instead of tracing for observability:

# OLD
spring.ai.openai.include-prompt=true
spring.ai.openai.include-completion=true

# NEW
spring.ai.openai.log-prompt=true
spring.ai.openai.log-completion=true

• Configuration properties renamed: include-prompt → log-prompt, etc.

• Added TracingAwareLoggingObservationHandler for trace-aware logging

• Replaced micrometer-tracing-bridge-otel with micrometer-tracing

Vector Store

// OLD
Optional<Boolean> result = vectorStore.delete(ids);
if (result.isPresent() && result.get()) {
    // handle successful deletion
}

// NEW
vectorStore.delete(ids); // Now throws an exception if delete fails

• The delete() method in VectorStore is now void instead of returning Optional<Boolean>

• Default value of initialize-schema property is now false

Template

Self-contained templates in advisors:

• QuestionAnswerAdvisor expects templates with query and question_answer_context placeholders

• PromptChatMemoryAdvisor expects templates with instructions and memory placeholders

• VectorStoreChatMemoryAdvisor expects templates with instructions and long_term_memory placeholders

Model Autoconfiguration

# OLD
spring.ai.openai.chat.enabled=true

# NEW
spring.ai.model.chat=openai
# Or to disable: spring.ai.model.chat=none

• The old properties for enabling/disabling models have been removed

• Use new properties instead: spring.ai.model.chat, spring.ai.model.embedding, etc.

Usage Interface

// OLD
Long generationTokens = usage.getGenerationTokens();

// NEW
Integer completionTokens = usage.getCompletionTokens();

• getGenerationTokens() renamed to getCompletionTokens()

• Token count field types changed from Long to Integer

Removed Implementations

Several implementations have been removed:

• Watson AI model (based on outdated text generation)

• MoonShot and QianFan (not accessible outside China)

• HanaDB vector store

• CassandraChatMemory implementation

Summary

We hope you enjoy the book as much as we enjoyed writing it. The next 6 - 12 months are likely to see even more rapid shifts and changes and we hope to write more about some of that here. We’ll hopefully also be able to get the examples available on the Apress repository updated to reflect the new release of 1.0.0.GA today.

To our success!

Subscribe now

This is part 1 of a tutorial series in building a Personal Finance App. In this series, we'll be building an Electron app that allows you to compute your total balance across multiple bank accounts, using real, live data from your actual accounts.

To complete this tutorial, you'll need to do the following:

• Have NodeJS installed and setup on your machine

• Sign up for a developer account with Plaid: Get Started with Plaid

The Plaid signup will be covered in more detail as we go.

What we're building

In this tutorial series, we'll be using Electron to build a small personal finance app by integrating with the Plaid Financial API. The main behavior of this app will be to aggregate expenses across your accounts so you can easily grep how much you've spent for the month.

Since this is the first post of this series, we'll simply be getting setup and linking one account to display the balance.

Just Give me the Source

Looking for the completed source for this post? You can clone it from Github: Spend Tracker Electron App

The Basics

First, let's review some basics.

What is Electron?

For those unaware, Electron is a NodeJS framework that allows you to build web apps as desktop apps and integrate with OS-level APIs, just as you would in a native app.

To quote the Electron website itself:

If you can build a website, you can build a desktop app. Electron is a framework for creating native applications with web technologies like JavaScript, HTML, and CSS. It takes care of the hard parts so you can focus on the core of your application.

This provides the possibility of the elusive ability to "write once, run anywhere". Of course, it can be trickier in implementation, but multiple companies have successfully pulled this off, including Slack, GitKraken, and WhatsApp.

There's a lot more to say about the specifics of Electron. For the sake of this tutorial, here are some basics that are helpful to know:

• Electron is a fork of Chromium. At its core, an Electron app is using a manager process to spawn webpages in separate helper processes, just as Google Chrome does with tabs.

• The manager process is referred to as the main process. Each webpage is referred to as a renderer process and manifests as an actual window in your app.

• Your app will manifest on the user's machine as multiple processes, just as Chrome does. For example, if your app is called Spend Tracker, it will show up in a Process List as:

  • Spend Tracker

  • Spend Tracker Helper

There are often multiple Helper processes running, especially if your app makes use of multiple windows.

What is Plaid?

Plaid is a FinTech company that provides a modern financial services API. Integrating with Plaid provides your users with the benefits of Plaid's phenomenal UX while handling all of the complexities of managing a user's financial data.

If you've linked a bank account to an app recently (such as on a platform like Coinbase), you may have encountered a nice widget that allows you to easily search for your bank and select an account. This is one of the core offerings of Plaid: the Plaid Link service, which is part of what we will be adding to our personal finance app.

Up and Running with Electron React Boilerplate

Now that we have the formalities out of the way. Let's dig in. If you've developed in React before, you're aware that there can be a lot of setup just to get and up and running with everything. This is why tools like Facebook's create-react-app are so useful - they handle all of the setup and allow you to quickly start developing the components that make your app unique.

Since we'll be developing our Electron app using React, it'd be great to have such tooling to handle all of the messy parts of setup.

However, from personal experience, I can tell you that create-react-app doesn't provide you the best development experience with Electron. create-react-app is rather opinionated about its implementation, resulting in situations like their deliberate lack of support for decorators.

Essentially, create-react-app forces you to work off of a certain folder structure that doesn't work so elegantly with how you'll likely want to structure your Electron app.

Fortunately, there are plenty of Electron React boilerplate repositories out there that handle the majority of the setup for you. For the purposes of this article, we'll use the following starter app:

https://github.com/chentsulin/electron-react-boilerplate

The instructions are in the repository, but all you need to do is:

git clone --depth=1 https://github.com/chentsulin/electron-react-boilerplate.git spend-tracker
cd $_
npm install
npm run dev

Within a few moments, you should see an Electron app pop up. It should have content which is very similar to the popular React demo counter app.

Minor Tweaks for a Basic UI

Now that we're up and running, let's just make a few quick adjustments for the purposes of our use case. To start, we simply want this app to display a number. So let's tweak the existing UI to make that happen.

To dig into the code, simply navigate into the app/ folder.

The main page of this boilerplate is stored in containers/HomePage.js. However, that page simply renders the Home component, stored in components/Home.js, which you should open to make the changes.

Navigating to the render method of the component we, see:

<div>
  <div className={styles.container}>
    <h2>Home</h2>
    <Link to="/counter">to Counter</Link>
  </div>
</div>

We can simply change this to:

<div>
  <div className={styles.container}>
    <h2>Balance</h2>
    <h3>$10,000.55</h3>
  </div>
</div>

Great, now you should see the following in the app:

Integrating with Plaid Link

Now it's time to integrate with the Plaid service itself. If you haven't already, you'll need to sign up for a Plaid developer account.

Signup for a Plaid Developer Account

You can sign up for the Plaid developer account here:

Get Started with Plaid

Once you've signed in, you have to request access for developer-level permissions. This level of permissions allows you to access live data, i.e. account balances from your real accounts, up to a certain limit. In this process, Plaid requires that you fill out a little bit of information about your project and your intentions for using their API.

Making this request will open a new ticket with the Plaid team via your account.

In the meantime, we can make use of their Sandbox environment to begin integrating.

By registering with Plaid, you should have been provided with three credentials:

• Client ID

• Secret

• Public Key

You can view these keys by navigating to: Account: Keys

The intended use case for Plaid is for your client app to communicate with a server you've set up. Your server manages the client ID and secret to prevent exposure through your client app. Your clients then submit the public key in their requests to your server.

The basic Plaid Authentication Flow looks like this:

• A user opens your app and interacts with the Plaid Link widget

• The user selects their institution through Plaid Link and logs in with their bank's credentials, sending the request directly to Plaid's servers.

• Your app receives a callback containing a Public Token to associate with this particular set of credentials.

• The Public Token cannot get the user's account data. In order to request account data, you must dispatch a request for an Access Token to Plaid with the Public Token, your client ID, and your app's secret.

• Once the Access Token has been retrieved, your app can fetch account data for the selected institution directly from Plaid.

Important Note: This App is Intended for Personal Use Only

In the above description of the authentication flow, you may have noticed that a server is involved. However, for the purposes of this tutorial, rather than deal with setting up a server, it's easier to just have everything embedded in the app.

This is not Plaid's intended usage for working with their API. If you were to distribute your app with your client ID and secret included, it would be easy for others to pull out your credentials and make free use of them.

What we're building here is a local, non-distributable app for demo purposes. Should you want to build this into something distributable, some options might be:

• The obvious: set up a server that integrates with Plaid in the intended way

• Bring Your Own Credentials: Constrain your user base to technical users, and provide the ability to enter client ID and secret into the app, with the promise that you don't ship their credentials off anywhere. Naturally, your app had better be open-source if you want to pull off something like this.

Having said that, as a reader of this post, you're most likely technically-minded; so you can simply build the app for yourself and use it as you see fit.

What is Plaid Link?

Plaid Link is a component of Plaid's service that provides a drop-in module with a secure, elegant authentication flow for each institution that Plaid supports. (Source)

It's a pretty sleek interface, so let's get it into our app.

Plaid Setup and Handling Storage

In order to work with Plaid, we're going to need to install two dependencies: plaid, and react-plaid-link.

The first, plaid, is Plaid's official npm package for interacting with their API. The second, react-plaid-link, allows us to easily integrate Plaid Link into our app as a React component.

So, let's install them:

npm install plaid react-plaid-link

With our dependencies installed, we can add our Plaid developer credentials into the app. As mentioned above, this is not how you would do it for a production-ready app.

First, we'll open up components/Home.js.

At the top of the file, let's import the two libraries we just installed:

import plaid from 'plaid';
import PlaidLink from 'react-plaid-link';

Next, let's place our credentials into the app as constants:

const CLIENT_ID = 'your-client-id';
const SECRET = 'your-secret';
const PUBLIC_KEY = 'your-public-key';

After that, we'll create a new constructor for the component to initialize the Plaid client and setup our initial state:

export default class Home extends Component {
  constructor(props) {
    super(props);

    this.state = {
      items: getItems(),
      balance: 0,
      loading: false,
      error: null,
    };

    this.client = new plaid.Client(
      CLIENT_ID,
      CLIENT_SECRET,
      PUBLIC_KEY,
      plaid.environments.sandbox,
    );
  }

Before we continue, let's talk a little bit about how we're going to track information from Plaid.

In Plaid's terminology, an Item is a link to a user's institution. As mentioned above, a Public Token is returned when a user links an institution, and we send that Public Token to Plaid in order to get an Access Token to retrieve account data.

For this first post, we're only going to calculate the balance from one institution, but we should set things up in a way such that there's not too much friction to add support for multiple institutions later.

Since we're literally working in a webpage, we'll make use of localStorage for the purpose of tracking what institutions the user has linked.

Here's the structure we'll use to track institutions in localStorage:

{
  items: {
    byId: {
      ins_9: {
        id: "ins_9",
        name: "Capital One",
        publicToken: "public-token",
        accessToken: "access-token"
      }
    },
    allIds: [
      "ins_9"
    ]
  }
}

In the above structure, we maintain an array of all IDs, and an object with the individual IDs as keys. This is a convenience that allows us to easily work with the data in either format.

localStorage only stores strings, so we'll be serializing and deserializing our objects to work with them. As such, it makes sense to define a few helper methods.

First, in localStorage, we'll refer to our data through a key, items. As a good practice, let's create a const to represent that key.

const KEY_ITEMS = 'items';

Next, let's define the method that will retrieve our items from localStorage. Additionally, the method initializes the object in localStorage if it's not already set.

const getItems = () => {
  let items = JSON.parse(localStorage.getItem(KEY_ITEMS));
  if (!items) {
    items = {
      byId: {},
      allIds: [],
    };
    setItems(items);
  }

  return items;
};

Then, we'll make a method, setItems, which simply updates the object:

const setItems = items => {
  localStorage.setItem(KEY_ITEMS, JSON.stringify(items));
};

Finally, we'll make a method addItem which makes use of both previous methods to add a new item to the object:

const addItem = item => {
  const oldItems = getItems();
  if (oldItems.byId[item.id]) {
    return;
  }

  const items = {
    byId: {
      ...oldItems.byId,
      [item.id]: item,
    },
    allIds: [...oldItems.allIds, item.id],
  };

  setItems(items);
};

The above method ensures that we dont add duplicate keys by checking if the ID is already in the object, and returns immediately if it is.

With these methods in place, we can now get to work at configuring our component to work with Plaid Link.

Integrating Plaid Link

The react-plaid-link component renders in our app as a button that the user can click to login to their institution through Plaid.

Our first changes will take place in the render method. As a reminder, this is what the method currently looks like:

render() {
  return (
    <div>
      <div className={styles.container}>
        <h2>Balance</h2>
        <h3>$10,000.55</h3>
      </div>
    </div>
    )
  }

Now let's update it to reflect the component's state and any institutions stored in localStorage.

First, in the beginning of the render method, we'll retrieve any state relevant to the UI, and also retrieve the items from localStorage:

const { balance, loading, error } = this.state;
const items = getItems();

Next, we know we want to display different messages in place of the balance depending on the state, so let's write those conditions:

let value;
if (loading) {
  value = 'Loading...';
} else {
  value = `$${balance}`;
}

We create a variable, value, which has a value of 'Loading...' if the component's state is loading, and otherwise displays the current balance. If the balance hasn't been computed, the component's initial state has the balance set to $0.

Now, let's make some tweaks to how elements actually get rendered, and include the PlaidLink component. We'll look at the whole chunk and then break it up:

return (
  <div>
    <div className={styles.container}>
      {!error && (
        <div>
          <h1>Balance</h1>
          <h2>{value}</h2>
        </div>
      )}
      {error && <h3>{error}</h3>}
      {items.allIds.length < 1 && (
        <div>
          <h3>Link to your bank to view your account balance.</h3>
          <PlaidLink
            publicKey={PUBLIC_KEY}
            product="auth"
            env="sandbox"
            apiVersion={'v2'}
            clientName="Spend Tracker"
            onSuccess={this.onItemLinked.bind(this)}
          />
        </div>
      )}
    </div>
  </div>
);

First, we only display the balance if there's no error (i.e. error is falsy). If there is an error, we display the error message instead.

{!error && (
  <div>
    <h1>Balance</h1>
    <h2>{value}</h2>
  </div>
)}
{error && <h3>{error}</h3>}

And then, we only want to render the PlaidLink component if the user hasn't linked any accounts yet:

{items.allIds.length < 1 && (
  <div>
    <h3>Link to your bank to view your account balance.</h3>
    <PlaidLink
      publicKey={PUBLIC_KEY}
      product="auth"
      env="sandbox"
      apiVersion={'v2'}
      clientName="Spend Tracker"
      onSuccess={this.onItemLinked.bind(this)}
    />
  </div>
)}

The parameters to PlaidLink are documented on the repository. Here's what's important to note:

• product is important - its values are essentially scopes of behavior for accessing Plaid. We're requesting auth because it allows us to view all accounts and overall balances. If we wanted to view individual transactions, we'd have to request transactions as well.

• env is set to sandbox. Once your developer account is approved, it needs to be changed to development to access your real financial data.

• onSuccess is the method that gets called once the user successfully logs into and links an institution. The callback, which we'll go into next, is the starting point for requesting account data.

Handling Data From Plaid

Before we can successfully run the app, we have to define how our app responds once the user has linked an account.

As mentioned above, the first thing we need to do is define our onSuccess method, which will be named onItemLinked:

onItemLinked(publicToken, metadata) {
  const { institution_id: id, name } = metadata.institution;

  this.client
    .exchangePublicToken(publicToken)
    .then(res => {
      const { access_token: accessToken } = res;
      addItem({
        id,
        name,
        publicToken,
        accessToken,
      });

      this.fetchBalance();
    })
    .catch(() => {
      this.setState({
        ...this.state,
        error: 'Unable to authenticate with service',
      });
    });
}

The method receives two parameters, publicToken and metadata. publicToken is all that we need to get an accessToken, but metadata contains information about the institution, such as name and ID, that we want to track.

Using the destructuring alias syntax, we access institution_id and store it as a variable, id, as well as name, from metadata.institution.

Now, we need to make another request. This is the request that allows us to exchange our publicToken for an accessToken. Using the Plaid client that we setup earlier, we invoke exchangePublicToken, which returns a Promise.

From the response, we can easily grab the accessToken.

It's at this point that we invoke our storage helper method, addItem. This synchronizes all the pertinent information about the user's linked financial institution, including the tokens. You might remember that Plaid refers to this as an Item.

Finally, we invoke another method, fetchBalance, which makes use of the accessToken to retrieve the total balance.

fetchBalance() {
  const items = getItems();

  if (items.allIds.length > 0) {
    const item = items.byId[items.allIds[0]];
    const { accessToken } = item;
    this.setState({ ...this.state, loading: true });
    this.client
      .getBalance(accessToken, {})
      .then(res => {
        const balance = res.accounts.reduce((val, acct) => val + acct.balances.available, 0);
        this.setState({ ...this.state, balance, loading: false });
      })
      .catch(() => {
        this.setState({
          ...this.state,
          loading: false,
          error: 'Unable to get balance.',
        });
      });
  }
}

This method also needs to be invoked from componentWillMount:

componentWillMount() {
  this.fetchBalance();
}

This ensures that, if the user reopens the app after linking an account, it can simply proceed to fetching the user's balance.

Diving into the fetchBalance method, we first retrieve the items from localStorage. Since we invoke this method from componentWillMount, it's possible that the user has not linked any institutions, and so we don't want to proceed if there's nothing to request from yet.

Once we're sure that they've linked an institution, we simply get the first institution in the list. This is because, for the purposes of this post, we're only focused on working with one institution right now. Later in this series, we'll look into managing multiple institutions.

Now that we have the institution, we can simply retrieve the accessToken from the item and invoke the Plaid method getBalance.

Once we've received a response, we use Array.prototype.reduce on the accounts array to sum up the available balances across all accounts and update the component's state to reflect the final amount.

And of course, if there is any issue that raises an error, we update the state to indicate that something went wrong.

That's All

And that's it for Part 1. To recap, we covered quite a lot in this post:

• Getting setup with Electron React boilerplate

• Understanding Plaid and how to integrate it into an app

• How to manage data from Plaid using localStorage.

• Integrating Plaid and Plaid Link into our component to successfully retrieve data from an institution

• Calculating the sum of balances across all of the user's accounts

In Part 2, we'll dig into:

• Linking and viewing multiple institutions

• Removing institutions

• Adding a refresh button

• Adding a filter to toggle different institutions

If you have any questions, don't hesitate to reach out in the comments.

When I was at Java2Days this year, I was pulled into a panel discussion about Cybersecurity, AI and Digitalization. The discussion ranged in talks about privacy, e-voting, and if artificial intelligence will take your job as a developer.

As a true lover of Star Wars, I was wearing my AT-AT shirt which you can find at Target.

Here's a quick shot from the Target website, and it looks awesome:

The other participants on the panel were:

• Linda Naeun Lee from Tor Project

• Steve Kosten (@skosten) from Cypress Data Defense

• Aaron Cure (@curea) from Puma Security

• Krasimir Kotsev

What do you think about the challenges we're currently facing with cybersecurity and privacy? Or the constant drumbeat of machine learning and AI getting ever closer to replacing what once was human-only functions? Let us know in the comments.

From georigami on flickr

My entry file with Redux Saga generally looks like this:

import {all} from "redux-saga/effects";

import {
    watchLoginRequest,
    watchLogoutRequest,
    watchCurrentUserRequest,
    watchUpdateProfileRequest
} from "./authSaga";

import {
    watchGetUserList,
    watchGetUser,
    watchAddUser,
    watchUpdateUser,
    watchDeleteUser
} from "./adminSaga";

export default function* rootSaga() {
    yield all([
        watchLoginRequest(),
        watchLogoutRequest(),
        watchCurrentUserRequest(),
        watchUpdateProfileRequest(),
        watchGetUserList(),
        watchGetUser(),
        watchAddUser(),
        watchUpdateUser(),
        watchDeleteUser(),
    ]);
}

As you can see a set of imports and then an array of functions added to the generator function used in my store module. This works fine, but I often find that swapping between a specific sagas file and the rootSagas file to be an unnecessary step prone to error.

In the individual saga, these list of functions that get called are pointing to non-blocking yields to handle the action types spawned from the action creators that in turn will call a generator function to handle that action type:

export function* watchLoginRequest() {
    yield* takeEvery(types.LOGIN_REQUEST, loginRequest);
}

These work fine, can be organized near the end of your individual sagas files, but the way I had it setup, contained too many places to edit and possibly miss.

I’ve taken the liberty of using some ES7 magic to fix my pain. Here’s the new rootSaga.js:

import {all} from "redux-saga/effects";
import { sagas as authSagas } from "./authSaga";
import { sagas as adminSagas } from "./adminSaga";

export default function* rootSaga() {
    yield all({
        ...authSagas,
        ...adminSagas,
    });
}

I like this a lot more, and when you have more than one saga, you can see how we just use the spread operator to combine things nicely. As an example in one of our saga files, here’s how we can handle our watch generator functions:

export const sagas = {
    watchCurrentUserRequest: takeEvery(types.CURRENT_USER_REQUEST, currentUserRequest),
    watchUpdateProfileRequest: takeEvery(types.UPDATE_PROFILE_REQUEST, updateProfileRequest),
    watchLoginRequest: takeEvery(types.LOGIN_REQUEST, loginRequest),
    watchLogoutRequest: takeEvery(types.LOGOUT_REQUEST, logoutRequest),
};

Can you see any way to inject any further brevity into the above? This pattern is common in a lot of our teams redux-saga code, and I like the way this looks for refactoring.

While integrating redux-saga an annoying little error may pop up in the console.

Uncaught ReferenceError: regeneratorRuntime is not defined

It took a bit of research to figure out why, and it shouldn't have since the notice is listed in the README for redux-saga. Most browsers do not support ES2015 generators, so require using a polyfill.

I am going to assume usage of the react-slingshot bootstrap as mentioned in a previous post about usable bootstrap with react-slingshot.

Add the import for babel-polyfill prior to importing redux-saga to the src/store/configureStore.js.

import 'babel-polyfill';
import createSagaMiddleware from 'redux-saga';

Enjoy.

<circle fill="#00D8FF" cx="299.529" cy="299.628" r="50.167"/>

<path fill="none" stroke="#00D8FF" stroke-width="24" stroke-miterlimit="10" d="M299.529,197.628

c67.356,0,129.928,9.665,177.107,25.907c56.844,19.569,91.794,49.233,91.794,76.093c0,27.991-37.041,59.503-98.083,79.728

c-46.151,15.291-106.879,23.272-170.818,23.272c-65.554,0-127.63-7.492-174.29-23.441c-59.046-20.182-94.611-52.103-94.611-79.559

c0-26.642,33.37-56.076,89.415-75.616C167.398,207.503,231.515,197.628,299.529,197.628z"/>

<path fill="none" stroke="#00D8FF" stroke-width="24" stroke-miterlimit="10" d="M210.736,248.922

c33.649-58.348,73.281-107.724,110.92-140.48c45.35-39.466,88.507-54.923,111.775-41.505

c24.248,13.983,33.042,61.814,20.067,124.796c-9.81,47.618-33.234,104.212-65.176,159.601

c-32.749,56.788-70.25,106.819-107.377,139.272c-46.981,41.068-92.4,55.929-116.185,42.213

c-23.079-13.31-31.906-56.921-20.834-115.233C153.281,368.316,176.758,307.841,210.736,248.922z"/>

<path fill="none" stroke="#00D8FF" stroke-width="24" stroke-miterlimit="10" d="M210.821,351.482

c-33.746-58.292-56.731-117.287-66.312-166.255c-11.544-58.999-3.382-104.109,19.864-117.566

c24.224-14.024,70.055,2.244,118.14,44.94c36.356,32.28,73.688,80.837,105.723,136.173c32.844,56.733,57.461,114.209,67.036,162.582

c12.117,61.213,2.309,107.984-21.453,121.74c-23.057,13.348-65.249-0.784-110.239-39.499

C285.567,460.886,244.898,410.344,210.821,351.482z"/>

</svg>

Getting started with [React](https://facebook.github.io/react/) can be a bit daunting, and as with using things like AngularJS I've found that using a bootstrap is a great way to start. With that in mind, I've chosen the wonderful [react-slingshot](https://github.com/coryhouse/react-slingshot) from [@housecor](https://twitter.com/housecor). It contains a demo which can be removed with an `npm script` and from which we'll extract what I feel is most useful including: integration with redux, react-router, and redux-thunk.

Most [React](https://facebook.github.io/react/) repositories seem to dispense with build tools and instead use a mixture of npm scripts and webpack to achieve what it needs to achieve. Just recently a new package manager came out to unseat the stalwart in `npm`, we're using [yarn](https://yarnpkg.com), please follow the install instructions for your particular environment.

<!--more-->

Clone the `react-slingshot` repository using the following `git` command:

% git clone git@github.com:coryhouse/react-slingshot.git

First thing we'll do after cloning `react-slingshot` locally is remove the demo as it isn't useful any longer

yarn remove-demo

## Main entrypoint

Let's add the necessary items for using redux and integrating react-router. Open up the `src/index.js` and paste the following in:

/* eslint-disable import/default */

import React from 'react';

import {render} from 'react-dom';

import { Provider } from 'react-redux';

import { Router, browserHistory } from 'react-router';

import { syncHistoryWithStore } from 'react-router-redux';

import routes from './routes';

import configureStore from './store/configureStore';

const store = configureStore();

const history = syncHistoryWithStore(browserHistory, store);

render(

  <Provider store={store}>

    <Router history={history} routes={routes} />

  </Provider>,

  document.getElementById('app')

);

Let's take this in chunks, the eslint bit is because there's no default export in this file and we want eslint to ignore that. Then we have imports for bringing in react, redux, and the integration with react-router and redux.

import React from 'react';

import {render} from 'react-dom';

import { Provider } from 'react-redux';

import { Router, browserHistory } from 'react-router';

import { syncHistoryWithStore } from 'react-router-redux';

The bootstrap already contains a working version to configure the store, and has the integration with `redux‐thunk` for the middleware. We call the exported function to configure the store, and then `syncHistoryWithStore(browserHistory, store)` will save our router state in the redux store.

import routes from './routes';

import configureStore from './store/configureStore';

const store = configureStore();

const history = syncHistoryWithStore(browserHistory, store);

This snippet is the entrypoint for our application. The `Provider` component is offered by `redux` and allows us to wrap all other components with access to our store, and inside that we add the `Router` component with access to our store-saved history, and the routes which we will define in the next section. That's it for our index module, let's move on to defining some simple routing.

render(

  <Provider store={store}>

    <Router history={history} routes={routes} />

  </Provider>,

  document.getElementById('app')

);

## Routes

Now we'll define our routes module which was referenced in the index file. Create a new file in `src/routes.js` and paste the following in.

```javascript

import React from 'react';

import { Route, IndexRoute } from 'react-router';

import HomePage from './pages/HomePage';

export default (

<Route path="/">

<IndexRoute component={HomePage}/>

</Route>

);

```

This is a typical [react-router](https://github.com/ReactTraining/react-router) file, and you can browse the documentation to find more ways to customize things.

## Pages

You may have notice we've identified another missing file `src/pages/HomePage.js`, which we will create now.

```javascript

import React from 'react';

const HomePage = () => {

return (

<h1>Hello, World!</h1>

);

};

export default HomePage;

```

This is the simplest of components, a functional stateless component which merely outputs Hello, World! wrapped in an H1 tag. If you attempt to run things now you will still receive errors in the reducers directory. While out of the scope of this quick tutorial, reducers are how an application's state changes in response to something happening, you can [read more in the Redux docs](http://redux.js.org/docs/basics/Reducers.html).

Let's open `src/reducers/index.js` and modify with the following:

```javascript

import { combineReducers } from 'redux';

import {routerReducer} from 'react-router-redux';

const rootReducer = combineReducers({

routing: routerReducer,

});

export default rootReducer;

```

Remember, we added `react-router-redux` to our index module, so as our first reducer we need to at the routerReducer to the list of reducers offered up in the `combineReducers` call. It's in this file that you can define more reducers to be included in your `redux` stack.

## Fin

With that, browse to http://localhost:3000 and see the familiar "Hello, World!". There is so much more to be done, we can dip into the `redux` portion and start defining actions, action creators, reducers, and use `redux-thunk` for the inevitable need for asyncronous calls in our action creators. This is a first step, stay tuned and we'll dig even deeper into the React / Redux stack.

And if you weren't in Sofia, Bulgaria for [CodeMonsters](http://codemonsters.pro/)/[Java2Days](http://2016.java2days.com) this year, my presentation on [React and Redux](http://www.slideshare.net/kinabalu/react-and-redux) is available on slideshare. Thanks to everyone who was in attendance,

It's gotten to be a yearly event to visit Sofia in the early part of winter. I'll be visiting again in a few weeks for the conference on the 18th and 19th of November. The Java2Days conference is a mix of Java, Cloud and Mobile development talks and has always been a great time. Between the wonderful hosts who organize the event, to the awesome attendees, it's definitely a conference to make time for every year.

Hope to see some of you there if you're anywhere near Bulgaria. And if you're in Portugal over the next week, I'm there too.

Ciao!

We're nearing completion on writing a book for O'Reilly about WebSocket. The book will be released soon as currently available in Early Release on the publisher's site. It's been quite a ride taking the concept from a blank page, to over 150 pages of in-depth discussion about WebSocket and I'm totally excited to share it with you soon.

This is something we've never embarked on before. Our main focus has always been offering tech solutions for business problems, giving trainings, and evangelizing and teaching technology in conferences worldwide. Writing a book has been on the goal list for years now, and I'm grateful that I got the opportunity to do so with the team over at O'Reilly.

Special thanks go out to Stephan Spencer who helped push me into getting this thing done, and many others who cheerleaded along the way.

Here's a look at the table of contents:

• Chapter 1 - Quickstart

• Chapter 2 - WebSocket API

• Chapter 3 - Bidirectional Chat

• Chapter 4 - STOMP Over WebSocket

• Chapter 5 - WebSocket Compatibility

• Chapter 6 - WebSocket Security

• Chapter 7 - TBA

• Chapter 8 - WebSocket Protocol

Thank you to everyone involved, and please buy the pre-release if you're interested, and learn about WebSocket technology today.

In a few years it may be possible to get a degree in writing headlines for websites looking to suck in readers. BuzzFeed, Gawker and similar have mostly mastered the art of misdirection, pulling you in with a shocking or tantalizing headline only to be let down by the relative ho hum of the payoff. Videos that we've seen several times, the tear jerkers, the shocking, the unlikely hero who doesn't hold our idea of beauty but can really sing.

A colleague of mine sent an article about "The End Of Apps As We Know Them". Given that here at Mystic we're in the app development space, this is of particular interest.

The basic premise, is that the new paradigm for designing and delivering apps to end users is:

1. Designing systems and not destinations

2. Notification screens in iOS 8 and Android are going to be really huge

I don't disagree with most of the article. I have found like countless others, that the expanded toolset available via a notification to be very handy. The expanded nature of the share button to include extensions and other share options are also serving a much needed hole in the mobile experience (looking at you Pocket and 1Password).

It goes off the rails for me in the narrow approach to how apps are changing. When I read it, I agree with the obvious, that apps are expanding into other areas of the phone, offering us new ways to consume content. It treats the reader as if they are a mere consumer of content, and not the creator. Consumers of content are interesting for their value to an app, websites, etc. Creators haven't seen enough change in how content is crafted on mobile other than Siri not sucking that much anymore.

What are your thoughts? How has creating in the mobile space evolved for you?

We've decided to take the plunge and do a quick redesign of the site. The old one was getting a bit long in the tooth, and we couldn't see subjecting anybody to that design any longer. As such, if you see any errors on the site, missing links, big foot, etc, please hit us up on social media and tell us. We're using Jekyll to power the site, and hosted over at Github Pages to keep things super simple.

Look for the old blog posts to be backfilled in here once we figure out how to work the jekyll-import tool

Our Java2Days talks have been completed. There is still another day left of amazing talks by amazing speakers. Can't wait to see more talks about WebSockets, OhmDB, and more Java technologies.

Our talks:

• Building iOS Applications with JavaScript

• Real Time with Websockets

Both talks are usingreveal.jsfor display purposes. Thank you again for everyone who attended and participated with questions in the talk.

If we spend any time on the tubes, we know that the internet is a large and wonderful place. It has allowed us to communicate and shrink the world, and learn whatever we wish to learn along the way. This could be how to fold a fitted sheet, learn the meaning behind string theory, or watch some stars spoof an already disturbingly odd music video (cheers Kanye). More and more the useful and useless stuff comes via known suspects: Facebook, Reddit, Twitter, etc.

So if you'd like to give yourself a timeout, because you have no self control (I don't, it's cool). Use SelfControl.app and give yourself freedom from whatever sites are wasting your time while you're trying to get actual work done. Edit the blacklist, and add the half of the internet that is useless, which usually comes from the above sites first. After starting, those websites will now refuse to load.

Perfect.

Curiosity though, always gets the better of me. And while their FAQ states that once SelfControl starts, it can't be stopped for the duration ... that's simply not true. Since we're on a Mac, and we've got a BSD backend, there had to be a firewall involved. So if you'd like to see a list of all the IP addresses (the blacklist sites) that SelfControl is blocking:

% sudo ipfw list

Take a look at the line that says "count ip from any to any // BEGIN SELFCONTROL BLOCK" and ends with "count ip from any to any // END SELFCONTROL BLOCK". All of these IP addresses are what you have asked to block and with a flick of the wrist, this can all be undone. For each IP address within the block, there is a 5-digit identifier number, e.g. 01518. Armed with this simply type:

% sudo ipfw delete /insert number here/

Browse what you want yet again. Waste all the time in the world. I apologize in advance.

Have you ever looked at the home screen on your smartphone, and wished that there was a different set of icons on that initial screen? You're driving, so the Messages app, the Camera, Calculator, etc should all be relegated to another screen, hidden away from frisky fingers. Or you're at home, so the Maps application isn't going to be as important, but Spotify and Pandora might, and Safari, etc. Or you've decided to take a trip to a foreign land, and you need the translator, Yelp, Whatsapp, OffMaps, and any other number of apps that are more geared toward your out of country experience.

How would this be achieved?

One way could be, Bluetooth.

StickNFind is an indiegogo project with miniscule Bluetooth location stickers that you can place all over the joint. So when your phone / iPad senses you going into the kitchen, it could swap around the icons so that all the cooking apps show up. Or if you move into the living room, all streaming apps get moved to the home screen. One sticker goes in the car, and your phone understands that you're about to go for a drive, so the Messages app moves out, and safe driving apps move in.

Another way in addition to that, could be Siri.

"Siri, I'm going for a drive".

"Okay batman, I'll change your homescreen for driving"

And yes, Siri calls me Batman.

All of the technology we have now, I want a few more lifestyle adjustments. To make this work seamlessly of course, it would require being a part of the OS. I'm not sure if Apple would ever do something like this, but if any jailbreakers are listening, I'd be happy to jailbreak the phone to get this tech.

Bulgaria.

This year, as with every year was an amazing experience filled with rich technical content, amazing speakers and attendees delivering an awesome conference. As promised, here are the presentations and information on the three presentations delivered this year.

The HTML5 Landscape

This year, we showed some new demo items, along with layout for the HTML5 landscape talk. From now forward, we'll add to the following repository "HTML5 Demo" and add cool new demos as we have them.

Using Javascript to Build Native iOS Applications

For the Javascript builds your iOS application talk, we built an example grabbing the current weather from Open Weather Map. Take a look at the repository "MobileWeather Titanium" and if you'd like to help spruce it up, let us know.

Advanced techniques for mobile games with HTML5

This year, we were asked to co-present with one of the developers at

http://www.cayetanogaming.com

. We advised the team on some ideas for how to organize, and also took over a large portion of the presentation to spice it up, and make it more fun. On advisement Kristiyan from Cayetano built out a balloon shooting game available here: Balloon Shooter.

Thank you again for everyone who attended this year, and as always, feel free to contact me if you have questions about anything.

Recently I gave several talks in Europe at Scandev on Tour in Stockholm and Java2Days in Sofia. Each time I've given a talk, I'm not only teaching up there, but learning from the crowd. It's an immense and enjoyable experience, and a great passion to impart information and knowledge to those who attend my talks. So, thank you, I am deeply appreciative and immensely grateful for everyone who has attended my sessions.

It has just been released that Adobe is no longer going to be developing Flash for mobile devices. This further solidifies what I discussed in my HTML5 talk in Sofia. Mobile has decided that HTML5 shall be the next frontier for interactive development.

And here's some of the stuff we talked about:

• The HTML5 Landscape

• Using Javascript to Build Native iOS Applications - Given in Stockholm and Sofia

• An in depth look at Apache Wicket - One of my favorites as I have a deep abiding love for Apache Wicket

And last but not least, I promised the source code to the iOS app written in Titanium. Here's one of the latest revisions which covers using it with the Scandev speaker data, but can be modified to support really any of the conference websites.

Speakers iPhone App

The first computer I spent any time on, was an Apple ][.

Three decades later, I'm writing this on an iMac. And many of you will read it on some Apple-designed device whether it be a Mac, iPhone, iPod Touch, or iPad. The company at the forefront of several revolutionary products, Apple, just lost their Wonka yesterday. We all feel a sense of loss at his passing, I consider him one of the fathers of modern computing. No other iconic figure represents the inventions and devices that many of us use every day like Steve Jobs did.

For the last 14 years, he rebuilt the company he created from the ground up to be one of the strongest in the world. And how did he resurrect a company that was near death? Passion and a love for the work.

Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.

Love what you do, and follow your heart. It's the only true north you can count on, to take you forward in life.

So many things he brought into creation have dazzled us, and changed the face of industries thought to be immovable. The company he cultivated and taught to be insanely great, yet again, is his legacy. When his resignation came on August 24th, 2011, there was something prophetic in the letters words, and it lingered in the back of my mind:

"I have always said if there ever came a day when I could no longer meet my duties and expectations as Apple's CEO, I would be the first to let you know. Unfortunately, that day has come,"

A little over a month later, unfortunately, that day has come.

Our condolences to his family for their loss. Every one of us that he had an impact on, have a bit more illumination and color in our lives thanks to his passion.

"Stay Hungry, Stay Foolish"