Explore our thinking

The next generation of React, aka Fiber, is eagerly anticipated. Expero's front-end team chimes in with their first impressions. If you’re like us, you’re eagerly awaiting the release of the new version of React (commonly referred to as React Fiber). We don’t intend to comprehensively go into the differences between React Fiber and the current React architecture (code named React Stack). However, when upgrading React, explicitly deprecated features tend to be pretty straightforward and easily called out with tooling like eslint. Still, some changes can be more insidious as they may have side effects that will be difficult to spot or reliably reproduce.

In this session of our client-server to cloud seminar series, we share proven methods for determining if modernizing makes sense for your application, a checklist of considerations, and a Lean process for creating a sound modernization strategy.

Is your software built on sunsetting technology like VB6, .NET, etc? Do you have low user satisfaction because of outdated software? Does it take too long to develop and roll out new features? Are you losing ground to solutions that offer mobile versions? Is it becoming difficult and expensive to maintain staff with legacy knowledge? Is your on-premise legacy infrastructure costly to maintain?

Trying to modernize monolithic legacy applications is hard: these applications are core drivers of the business and the risk of messing them up is too great. However, as time goes on, the cost of maintaining these monoliths grows.

In this blog post, I'll discuss the process of building a micro service that is backed by a graph database and the technologies leveraged to accomplish it. I'll be building this microservice in Java using Maven for its declarative dependency management and build process and Dropwizard for its straightforward architecture and configuration, and then connect everything up to an Apache Tinkerpop enabled Graph Database.

We get asked that question a lot given our early customer work with Titan evaluations, participation in the JanusGraph project and usage of Apache TinkerPop while concurrently being a premier DataStax Graph partner.

DataStax released 5.1, Neo4j released 3.2, Microsoft announces CosmosDB; there’s a lot of stuff happening in the graph database world. Looks like a prime time for some Gremlin training.

Scott Heath and Patrick McFadin talk about how Expero and Datastax are partnering together to solve complex problems with graph data.

Software and web developers often wear many hats, including the UX/UI hat. But some developers lack the knowledge to design UIs or to collaborate effectively with UX designers and researchers.

Software and web developers often wear many hats, including the UX/UI hat. But some developers lack the knowledge and skills to design UIs or to collaborate effectively with UX designers and researchers.

Companies across a variety of industries are trying to attain a holistic view of their customers. From creating a more personalized experience, to creating more timely and relevant support, to simply marketing to them more efficiently and effectively, there are tremendous gains to be had with a 360-degree view.

As a user researcher, I’m always inclined to say, “Test everything, all the time!” when people ask, “What/when/how should we validate with users?” That’s my pie in the sky: the place where there’s all the time and all the budget in the world to get every last detail or spec just right for the good of the user, the product, and, ultimately, the business. But that’s not real life. Projects run on strict budgets and tight timelines, and there’s not always a lot of wiggle room.

Do you remember the first time you saw a commercial about “the Cloud?” That was one of the pivotal moments for technology buzzwords going mainstream. It’s been a nonstop thrill ride since then: Web 2.0. Internet of Things. Big Data. Machine Learning. Like “the Cloud,” the term “machine learning” is thrown around a lot, but it’s not entirely clear who it is useful to. People who follow it are aware that machine learning techniques were used by Google to create an unstoppable Go playing machine, and that it allows computers to drive with abilities getting closer to human drivers by the day.

Congratulations! Your data is up and running in a graph database and you have big plans for this technology. But now the system is overtaxed and not performing properly. Don't worry- the database may not be the culprit. Proper user experience and visualization techniques can greatly improve performance and dynamic data interaction.

Webinar presentation on how to combine Graph databases with an iterative, user-driven approach and the latest UI tools to enable your team to start creating valuable user experiences with graph data.

This year at the Data Day 2017 conference in Austin,TX, keynote speaker Emil Eifrem declared 2017 the Year of Graph. Graph data storage certainly is becoming more mainstream, with a myriad of both commercial and open-source options currently available and maturing at an accelerated pace. But so what? Why should user experience practitioners, or anyone else that is not a database administrator, care about this trend in data storage technology?

What does the term “search” mean to you?

A quick recipe for bringing up your first web worker with Webpack in the mix and share some tips to keep your implementation clean.

Web application types include static website, traditional server-side rendering, client-side single-page application, and isomorphic single-page applications.

Product owners and stakeholders have a tendency to skip over discovery research and go straight to design—and then skip over validation research and go right to release. One of the main drivers behind this tendency is the fact that looking at designs is fun. Looking at numbers and bulleted lists of findings is not (as much) fun (for stakeholders). With designs, they get to see their product progressing and growing from inception to build. Data is more behind-the-scenes; it may drive design, but so what?

What are the next big trends in UX? At our recent Expero Summit, we discussed many advances that promise to transform how users interact with technologies. As augmented reality and other technologies take substantive form, it’s more and more about what the user needs from these amazing technologies and less about how cool the technology actually is. It’s a given that the technology is only going to get cooler. What’s not as obvious is whether the user is ready for it.

One of the major hesitations from product stakeholders regarding end-user engagement, specifically user testing, is that they often don’t want anyone to see it till it’s “perfect” or “ready” or “MVP.”

A supernode is a vertex with a large number of edges. In graph theory, these high-degree vertices are known as hubs.

When designing and developing software, it is critical to take into account the limitations of the technology employed, especially hardware—things like computers, boxes and other physical devices. But there’s another aspect to hardware that should be taken into account and is often overlooked: the user.

OrientDB is one of several popular graph data stores on the market today. It provides a multi-model approach with the powerful nature of a graph database and the flexibility of a document data store. If you have decided to build out your multi-tenant application on top of OrientDB, you are in luck as it has several built-in, out-of-the-box methods for handling multi-tenancy.

How do you handle customer #2? You delivered an MVP of some hosted software for customer #1. Your brother-in-law knows a guy who has a similar problem and after a lunch meeting, now you need to add customer #2 to your incubating SaaS tool. Of course customer #1 and customer #2 shouldn’t be able to see each other’s data, but you don’t necessarily want to install and configure everything all over again just because you added another customer.

In one of the projects Expero worked on several years ago, the client chose to build their own custom authentication solution. For three weeks, one developer’s status at the scrum every morning was “security.” It took that competent developer several weeks to get a very basic custom solution in place. Additionally, that solution didn’t even have integration with other identity providers or any other bells and whistles! You can easily double that estimate if you want even a few providers and a user interface that doesn’t look drab.

Neo4j is the most popular graph data store available today. It leverages graph technologies to help build modern high-performing applications, but it does not have any native multi-tenant support. However, you may have decided to build out your multi-tenant application and that Neo4j is the right graph data store to fit your needs. In any multi-tenant system, the trick (from a data-store side) really comes down to how to isolate one tenant’s data (physically or logically) from another tenant’s.

So you’re going to build a multi-tenant application and now it’s up to you to figure out how to make it all work. Ask any software engineer who has built one and they will tell you that multi-tenant applications are inherently more complicated than single-tenant applications. That complexity comes from the added overhead required to ensure that your tenants’ data are secured and isolated from one another (e.g., Tenant 1 can’t see Tenant 2’s customer list) and that large tenants don’t adversely affect other tenants in the same environment (e.g., Tenant 1 does not use all the resources, thereby slowing the performance for Tenant 2). The overhead caused by these requirements may take the form of either operational or developmental complexity, but the key to building an effective system in any multi-tenant scenario is to reduce that complexity.

Among the product announcements from AWS re:Invent 2016, a new triplet of production web services has emerged under the heady title of Artificial Intelligence.

Whether it’s a stand-alone service, a microservice or a back end for a web application, a consistent and robust API is no longer something to be handcrafted. Using an API framework likeSwagger promises to give you a leg up and help you build a robust API for less cost.

Visual design is about more than keeping up with popular design trends, especially for complex apps

We all know how awesome user personas are. They help all the king’s men—designers, researchers, product owners, stakeholders, investors, on and on—understand a particular user type’s behaviors, needs, goals and motivations.

Our spin on how UX teams have continued to tailor our UX design principles to the product development process.

DataStax Enterprise 5.0 contains much more than a version bump of its component pieces. In particular, DSE 5.0 includes the new graph database, DSE Graph. DSE Graph is an Apache TinkerPop enabled distributed property graph database that uses Apache Cassandra for storage, DSE Search for full text and geospatial search, and DSE Analytics for analytical graph processing.

Lean UX and the Agile mind-set are all about efficiency - emphasis on forward progress, no project management bells and whistles, cut the deliverables, go-go-go.

As Agile principles and Lean methodologies continue to take center stage in product management and strategy, it’s easy to get caught up in daily scrums and design iterations and shoot right past the user research (UR).

If you know anything about Expero, you know we specialize in solving “complex problems.” This means we’re not working on your average brochure website or e-commerce app. We’re tackling apps and softwares targeted to niche domains with expert end-users who have very specific needs and goals to solve their very complicated problems.

Using Google gRPC and Apache Cassandra to create a high-performance data pipeline for storing time series data that comes from IoT-style applications.

Over the past few months I got my first chance to work with Kafka Streams. For those who don’t know, Kafka Streams is a new feature in Kafka 0.10.0 that adds stream processing capabilities into the existing Kafka platform.

Josh Perryman visited the Northwest in July 2016 for DataDay Seattle and gave an updated version of my Graph Database Shootout.

Continuous Discussions is a weekly online panel discussion which is sponsored by Electric Cloud and discusses a variety of topics around Agile, Continuous Delivery and DevOps with a range of different speakers.

Expero's Dave Bechberger was invited to participate in an online panel focusing on DevOps and Security which was put on by Continuous Discussions (#c9d9). Continuous Discussions is a weekly online panel discussion which is sponsored by Electric Cloud and discusses a variety of topics around Agile, Continuous Delivery and DevOps with a range of different speakers. The panel discussed the role that DevOps plays with respect to Security. This topic was broken into several different sections: Securing your Code, Securing your Environments, and Securing your Process.

How can you retool your SQL talent to deploy on your graph project? According to Google Trends, interest in graph databases is increasing while SQL interest is level or even decreasing – but SQL searches are still 43 times more prevalent than graph.

Graph databases are a new paradigm for many folks. Hear Apache TinkerPop committer Ted Wilmes introduce graph topics and map them to their well-known SQL cousins.

Achieving user adoption goals for enterprise software can be challenging.

The Austin Data Geeks & Austin Graphs Meet-ups invited Josh Perryman to do an encore presentation of our GraphDay presentation: Graph Database Engine Shoot-out.

A case study at Graph Day recounting a client study we did to see whether their database could be reorganized to offer improved query performance. We looked at graph databases (OrientDB, Titan, Neo4J) because they thought of their data as graph data, and relational (Postgresql) because that’s what their database already implemented.

‍We are in an era of unprecedented innovation in databases. Data-intensive companies are grappling with whether the many new options — NoSQL, Key-Value, Document, Column Family, Column-Oriented — are appropriate for them. The commercial success of Facebook and LinkedIn makes graph databases a hot area of investigation. Unlike many new databases, they are not a variation on or a simplification of relational databases. Instead they require new ways of thinking and modeling data. In return they can answer truly novel questions.

We are in an era of unprecedented innovation in databases. Data-intensive companies are grappling with whether the many new options — NoSQL, Key-Value, Document, Column Family, Column-Oriented — are appropriate for them. The commercial success of Facebook and LinkedIn makes graph databases a hot area of investigation. Unlike many new databases, they are not a variation on or a simplification of relational databases. Instead they require new ways of thinking and modeling data. In return they can answer truly novel questions.

In this post we are going to explore a slightly more complicated yet common scenario involving continuous deployment of a .NET web application.

If your application does anything interesting, it has secrets. No, not that no one remembers how your code works, or that that one dev put a curse word in his checkin once. Not those kind of secrets. We’re talking about database passwords, secret API keys, per-user encryption keys, and the like. For a long time, web developers put those in configuration files or read them from files which programmers promised never to accidentally check in. Cross your heart.

In this post we will examine a simple scenario involving the deployment of a .NET based web application to an Azure Web App using Azure Key Vault for secrets management. All the code used for this blog post can be found here.

In this post we summarize what sorts of questions we feel like a proof of concept project around graph databases can answer, and how we typically tackle them.

We are meeting more people who are interested in looking into the world of graph databases. Palladium has executed proofs–of–concept for clients to help them explore this world. In this post we summarize what sorts of questions we feel like a proof of concept project can answer, and how we typically tackle them. For our presentation at Graph Day, we’ll be walking through one in particular, but really there are a variety of answers you may want.

Everyone gets delusions of grandeur!” That’s what Han Solo said after being frozen in carbonite. I’ve been solving data problems for customers the last year and a half and am now getting back in graph DBMSs. We took a nice look at Titan last week, can’t wait to play with that some more. I’m going to give a bit of the same to Neo4j. All of this as prep for my talk at GraphDay 2016 in Austin, TX.

Smartphone and tablet experiences are a major force influencing product development, irrespective of industry, according to an internal survey we recently conducted with our clients. Business users want to access their software applications from a myriad of devices, all behaving correctly regardless of form factor.

As part of the work we’re doing to refresh our graph database evaluation for a couple of clients (and our upcoming talk at Graph Day!) we took Titan 1.0out for a spin last week. We’ll be doing more in-depth explorations on some in-house and public datasets over the next few weeks, but here’s some preliminary impressions based on a contrast with the Titan we came to know a year ago or so.

Our client’s legacy system held graph-like data in a relational database, but new customers’ data sizes were crippling performance and scale. As part of an overall architectural rejuvenation, we evaluated migrating their data to graph and relational schemas to determine if query performance and scalability could be improved. With representative data in hand, we designed alternate relational schemas, graph database designs, and triple store designs, benchmarking performance and noting subjective measures such as ease of use and fluency of the query language. Vendors included PostgreSQL, Neo4J, Titan, and AllegroGraph. Follow-up studies included other vendors. The results surprised us, leading to a hybrid relational and graph recommendation. We have implemented the first milestone over the last year. Follow-up work shows that graph DB vendors have come a long way even in that time. This methodology and information in this case study should be useful to teams choosing a database engine, whether graph or relational, for their next project.Our client’s legacy system held graph-like data in a relational database, but new customers’ data sizes were crippling performance and scale. As part of an overall architectural rejuvenation, we evaluated migrating their data to graph and relational schemas to determine if query performance and scalability could be improved. With representative data in hand, we designed alternate relational schemas, graph database designs, and triple store designs, benchmarking performance and noting subjective measures such as ease of use and fluency of the query language. Vendors included PostgreSQL, Neo4J, Titan, and AllegroGraph. Follow-up studies included other vendors. The results surprised us, leading to a hybrid relational and graph recommendation. We have implemented the first milestone over the last year. Follow-up work shows that graph DB vendors have come a long way even in that time. This methodology and information in this case study should be useful to teams choosing a database engine, whether graph or relational, for their next project.

Unfortunately, I had to miss the live Apple event last week. So I took a little time this weekend to wade through it and came across this rather magical little multi-touch moment from the iPad Pro demonstration. To the untrained eye, simultaneously using a virtual ruler while drawing a line with a stylus may seem like standard fare. As a practitioner who has created multi-touch user experiences involving both stylus and touch inputs, I realize that this moment Apple depicts is not to be taken for granted. Here’s a breakdown of what’s likely happening to make this moment possible:

At Expero, we don’t like to just guess. We do under certain time constraints, but we want to get it right. That means finding out what the right design should be—and that means thoroughly evaluating options, often with feedback from stakeholders and end-users.

What do my users want to do with Big Data? How do they want to visualize it, interact with it and manage it? How big is my data, really? How much data can a human deal with at one time, and how much data should we process at one time? How can the UX accommodate data sources that respond at different rates?

What do my users want to do with Big Data? How do they want to visualize it, interact with it and manage it? How big is my data, really? How much data can a human deal with at one time, and how much data should we process at one time? How can the UX accommodate data sources that respond at different rates?

If you want to store lots of data, the Amazon cloud has buckets and glaciers for you, but not a shared file system.

asdlkf

Are you a Product Manager looking to show some early design directions to stakeholders and end-users? Are you a Developer needing a little more direction from the design team? Or a UX Designer or Researcher trying to figure out how detailed your designs need to be to communicate your intentions and get valuable feedback from users?

In this webinar, Expero highlights the major differences between static wireframes and interactive prototypes, shows examples of the design fidelity spectrum, and outlines the best ways to leverage wireframes and prototypes throughout the product design life cycle.

This post describes how to debug some library dependency issues on a Linux machine. I built a nightly version of Julia (a language for technical computing that we’re pretty excited about here), on Linux, deployed it to a different machine, but then it failed to launch, complaining about

As a user researcher, I am, of course, an evangelist of all things research. I love research! I love reading everything and learning everything and understanding everything I possibly can about a subject. Infographics are neat but I want more more more information! Give it to me—all of it! As a user researcher, I also, of course, realize that not everybody feels the same way. Often including clients.

I recently finished cleaning up our build system and adding support for both client-side and server-side unit tests. The build is cross-platform, meaning our developers can build and run the application whether they are on Windows, OSX, or Linux.

Ever wonder about the best way to visualize your application’s data sets?

Expero's Lynn Pausic and Chad Huff present best practices for creating useful and usable interactive visualizations for complex data sets, starting with ascertaining what your users will do with the data.

A design pattern, as we explained in our January 2015 blog post, is “a good, reusable solution for a common but specific interaction design problem.” In this online seminar, Lynn Pausic and I present design problems that are often seen in applications and sites with large or complex data sets. We also give 10 examples of patterns that can be used to solve those problems–things like how to set up a complex data table to view status at a glance, or when to employ column filtering so users see only what they choose to see.

Using UI design patterns can lead to a 50% increase in product development efficiency, and it can dramatically improve usability and user adoption.

What if, no matter how you try to simplify, your aggregate root is pretty darn big? Writing application services to handle these large entities is a challenge. We run into this all the time with scientific computing.

I’m a fan of Yahoo for news and email, but I’m not a fan of their new “two-tap rule.” The rule states that once a user is in a Yahoo application, it should take only two taps to do anything the user wants to do. Fast-to-use apps are the goal here. The two-tap rule sounds a lot like our field’s misguided “three-click rule,” which Expero cautioned against in 2007.

Several years ago, I attended a neat speech by a young but awesome UX Designer named Golden Krishna, with credentials ranging from product innovating at Samsung, to designing at Zappos, to writing for major publications. The speech was titled “The Best Interface Is No Interface,” and the room was packed—presumably full of user interface designers. It was a great hook.

Fascinating though it is, I’m happy to observe prison life from the outside through shows like Oz or Orange is the New Black. It’s the strange way prison mirrors the outside world that’s so compelling. They have police (gangs) and wars (gangs) and commerce (smuggling) and currency (cigarettes, stamps, etc.) just the same as the free world.

Is Google’s Material Design for complex software? My first reaction after reading through these new Google guidelines was: no. There’s no way these simple rules will translate seamlessly to complex enterprise-class applications—the kinds of projects that Expero excels at—at least not without starting over and removing 90% of the features/functionality that users want at their fingertips.

Many organizations haven’t embraced UI design patterns, despite their growing popularity among UX professionals. Those organizations are missing out on a ton of benefits for Product Management, Engineering, Marketing, UX and the business as a whole.

It’s hard to hire good developers. We face the same struggles everyone does in sorting the good from the bad. One of my favorite tropes is the resume as failed inductive proof.

In part 1 of this series, we looked at how using an IOC container helped us separate the concerns of the construction of a ZookeeperClient from the concerns of using it in service handlers. In this one, we look at how the IOC container can transparently help us manage a singleton which leaks memory.

IOC containers elicit strong emotions from programmers, ranging from reverence to disdain.

In the second part of this blog post we are going to look at a simple methodology for applications to take advantage of a centralized and transparent configuration store. I had thought this was going to be the hardest part of this project yet it turned out to be the most straightforward. This was done by implementing our own ProtectedConfigurationProvider class which gave us the ability to inject configuration data at runtime from any source available to me. I settled on this approach based on a lot of searching but which has been nicely condensed in several blog posts you can read here and here.

Our product suite (all .NET based) consists of a small but growing number of related applications with a lot of configuration data stored in app/web.config files with multiple environmental transforms. Much of the configuration is repeated across multiple projects in each environment (e.g. connection strings, email servers, etc.) so centralization of this data would be of great help. Currently, making even simple changes to any of these keys requires sifting through a large number of config files and transforms to make changes which is tedious, error prone, and difficult to test effectively.

ISPC Performance

Julia Performance

This the third post in a series, which started with a description of the problem, and continued with an F# benchmark.

There is still a substantial gap between this result and the result we’ll find with other environments, and my guess is this is a code generation issue, i.e. instruction selection and scheduling, but I’m not an expert in this area either!

I’ve got 405MB of 3D seismic data from Teapot Dome sitting in my file cache, and I want to give you a quick view of some of its summary statistics. How long do you think you should have to wait? If you’re working in Excel, you might be happy with a few minutes. A .NET programmer — used to endless database calls and virtual machines in his line of work — wouldn’t be too surprised at a few seconds, or tens of seconds. Long enough to fire up a spinny cursor and send you to Facebook, or whatever your work-day sin is.

In a previous post, we talked about untangling multiple UI controls so that they could be developed independently, but react to user interaction in a synchronized manner. Let’s posit for a moment updates to a line on one map control should cause re-rendering of a cross-section control associated with that line, but that the two controls are in different browsers, or even on different machines.

Reactive Synchronized UI Components: how I learned to stop worrying and love synchronized maps and cross-sections.

Recently I’ve come across the need to use an ambient logical context that would automatically flow with my program logic as it jumps from thread to thread. The .NET Framework has support for this when you are working with Threads and Tasks. It is not well documented, but it Just Works…mostly.

One of ZooKeeper’s nice features is the ability to set up a watch on a node, and be updated whenever it changes.

ZooKeeper’s “native” client APIs are C and Java. If you’re programming in .NET (or Python, or a few other languages), the docs helpfully point out that some friendlies have programmed clients that “might” work for you. “Might” is frustrating, as is the possibility that the libraries are behind. So we used the Java version anyway, and made it a little more idiomatic .NET. It turns out to be a nice look at how to use Java from .NET, and how to implement Task and IObservable patterns by by hand.

Okay, so you’re sold on using ZooKeeper to be your service locator or configuration repository. Your services will all talk to ZooKeeper when they start up to find out who they are, who their neighbors are, and generally how to get on with all the other animals at the zoo. But what service locator do you use to find out where ZooKeeper itself is? (ZooKeeper is actually in one or more places, since it typically runs on multiple servers in a production environment.) The answer probably depends on the scope of your problem: a 10,000 node cluster will be different than a few dozen services. Your best options are drawn from the service locator patterns already built into your OS or environment. Here we’ll talk about 3 options.

In the last post, we used ZooKeeper as a service registry. When services started, they registered with ZooKeeper at a pre-agreed place. (/services/{dataset-name}). Clients could list the data servers available and decide which ones to connect to, or request that new ones could be launched. Thanks to ephemeral nodes, servers can crash and their registry entries are automatically deleted. Today we’ll talk about three use cases for watching changes in ZooKeeper.

Zookeeper is a distributed database originally developed as part of the Hadoop project. It’s spawned several imitators: Consul, etcd, and Doozerd (itself a clone of chubby.) A lot of the material out there about Zookeeper describes just how it works, not necessarily what you’d use it for. In this series of posts, we’ll cover how we used it at one client — and it how it also got abused.

A good development team will already have a battery of tests in place to ensure their code is correct and can be refactored safely.

Turning from the open-source Titan to the commercial AllegroGraph was like stepping out of my 1998 4Runner and taking a spin my boss’s BMW. It was fast. It was sleek. It had all of the modern thingamajiggies that come with new, well-engineered solutions built by companies with the resources to do it well.