Shockoe Ranks No. 499 on the 2017 Inc. 5000 with Three-Year Sales Growth of 900%

Shockoe Ranks No. 499 on the 2017 Inc. 5000 with Three-Year Sales Growth of 900%

Richmond, VA – Shockoe, a leading disruptor in the design and development of advanced mobile solutions, is honored to announce that it has been ranked No. 499 by Inc. Magazine in the 36th annual Inc. 5000, an exclusive list of the nation’s fastest-growing private companies. This list represents the culmination of a review and ranking of one of the most important sectors in the American economy today – the entrepreneurs. It’s an honor to be named in a list where many of today’s well-known companies gained their first national exposure as honorees of the Inc. 5000, such as Microsoft, Zappos, Jamba Juice, Pandora, Timberland, LinkedIn, Yelp and Zillow.

We are tremendously proud of the work we’ve accomplished in the past few years and feel honored to be included amongst an exclusive and impressive list of growing companies on the Inc. 500,” says CEO Edwin Huertas of Shockoe.com. “Our growth over the years can be directly attributed to an incredible team and their ability to create innovative solutions for today’s ever-changing market coupled with the capacity to solve the most pressing challenges organizations face.”

The 2017 Inc. 5000, unveiled online at Inc.com and with the top 500 companies featured in the September issue of Inc. (available on newsstands August 16) is the most competitive crop in the list’s history. The average company on the list achieved a mind-boggling three-year average growth of 481%. The Inc. 5000’s aggregate revenue is $206 billion, and the companies on the list collectively generated 619,500 jobs over the past three years. Complete results of the Inc. 5000, including company profiles and an interactive database that can be sorted by industry, region, and other criteria, can be found at www.inc.com/inc5000.

About Shockoe:
Shockoe is a leader in the development of advanced mobile solutions focused on increasing sales, end-user experiences and employee productivity. Since our founding in 2010, our emphasis on today’s mobile consumer and end-user have helped us grow into a global consulting firm with a unique combination of mobile strategy, experience design, development, and integration. Our solutions have strong returns on investment, deliver excellent user experiences, and adhere to the best practices in security and reliability.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

The Richmond Times-Dispatch nominates Shockoe as one of the Greater Richmond Area 2017 Top Workplaces!

The Richmond Times-Dispatch nominates Shockoe as one of the Greater Richmond Area 2017 Top Workplaces!

Shockoe has been awarded a 2017 Top Workplaces honor by The Richmond Times-Dispatch. The Top Workplaces lists are based solely on the results of an employee feedback survey administered by WorkplaceDynamics, LLC, a leading research firm that specializes in organizational health and workplace improvement. Several aspects of workplace culture were measured, including Alignment, Execution, and Connection, just to name a few.

“The Top Workplaces award is not a popularity contest. And oftentimes, people assume it’s all about fancy perks and benefits,” says Doug Claffey, CEO of WorkplaceDynamics. “But to be a Top Workplace, organizations must meet our strict standards for organizational health. And who better to ask about work life than the people who live the culture every day—the employees. Time and time again, our research has proven that what’s most important to them is a strong belief in where the organization is headed, how it’s going to get there, and the feeling that everyone is in it together. Claffey adds, “Without this sense of connection, an organization doesn’t have a shot at being named a Top Workplace.”

About Shockoe

Shockoe is a cross-platform and native mobile solutions firm that specializes in building mobile apps and integrating legacy systems. We started in 2010  helping clients to develop mobile strategies which result in consumer and employee-facing mobile applications that meet users’ needs. We believe that technology can make the business better and make that belief a reality every day with the tools we build. We create apps for the entire supply chain – from Agriculture to Manufacturing and Logistics to Retail and Consumer Goods. As a result, we have built apps for Grocery Stores, Financial Firms, Insurance Companies, Consumer Goods, Retail Shops, and Pharma – We aim to get involved in a variety of projects to make sure that we are well versed in the mobile technology landscape.  As one of the leading mobile app development firms, we are focused on creating apps that provide engaging experiences for our clients’ employees and customers. Moving forward into 2017, we will work with companies to help them generate desired mobile experiences through integrating new technologies such as Voice Recognition, Augmented Reality, Virtual Reality, and Machine Learning. You can learn more about Shockoe and our openings , come to join the fun!

About WorkplaceDynamics, LLC

Headquartered in Exton, PA, WorkplaceDynamics specializes in employee feedback surveys and workplace improvement. This year alone, more than two million employees in over 6,000 organizations will participate in the Top Workplaces™ campaign—a program it conducts in partnership with more than 40 prestigious media partners across the United States. Workplace Dynamics also provides consulting services to improve employee engagement and organizational health. WorkplaceDynamics is a founding B Corporation member, a coalition of organizations that are leading a global movement to redefine success in business by offering a positive vision of a better way to do business.

Begin With the End in Mind

Begin With the End in Mind

“Begin with the end in mind” is the 2nd habit of Stephen Covey’s The 7 Habits of Highly Effective People. The driving rationale behind this habit is that if you envision what you want in the future, you can work and plan towards it. Utilizing this approach when managing Mobile App development projects is a central tenet to Shockoe’s project success.

We begin vision casting with our clients early and often. Project initiation is where the nature and scope of a project is determined. Although we become well versed in what you DO and what kind of systems and information you HAVE, what we really like to focus on is where do you want to GO and where do you want to BE. We help our clients learn to dream again.

Planning a project involves determining the time, cost, and resources needed to deliver a project successfully.  If you are clear on where you want to be, you can plan the project efficiently. Clarified purpose and common goals can then be communicated to the people involved. Clear goals, along with well planned tasks to align with those goals, help provide the proper motivation to tackle the project.

As project execution occurs, the coordination of the resources and deliverables against the planned activities will be closely monitored. A clear destination will allow you to accurately measure the steps you are undertaking. It will also allow the team to course correct quickly if they are not headed in the right direction.

It has been known to happen that (on occasion) the client’s vision of the future will change. Change is a normal and an expected part. Consistent, continuous communications will allow the team to understand the adjusted goals and assess any impacts. It will clarify the new version of the future and expectations can be set with regard to what will be required to now accomplish this revised vision.

With the end — the client vision and dream — in mind, Shockoe helps our clients plan and navigate into a future clearly driven by these goals. We always begin (and continue) with the end in mind.

[/vc_column_text][/vc_column][/vc_row]

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Points for Style

Points for Style

It’s been years, but I can still remember my lab partner’s frustrated exclamation clearly. “It’s not a rule. It doesn’t matter!”, let out in response to seeing the results of our automatically graded submission of a program in a mid-level Computer Science course. Our work was functionally perfect, but the grading tool had subtracted several points over incorrect indentation size and other various style errors. He was right, technically, as we had adhered to the implementation requirements and using our program would produce indistinguishable results from our classmates’, but the faculty had chosen to take a stand. They chose to force us to care about style, or at least notice it. They chose to enforce a few basic style guidelines at a time when it seemed irrelevant, a time when we did the vast majority of our programming as a single developer in a vacuum. I’m not going to say I saw the light immediately, and I don’t remember a single student arguing in the system’s favor early on. I did, however, adopt good habits that I would later come to be thankful for when I learned what is a shocking truth for many young devs:

Style is not extra credit. Style matters.

Now the vacuum is gone and there is no auto-grader, just a group of incredibly smart fellow developers whose time is valuable and sanity should be protected. I’ve been a strong advocate of vigilant style practices for quite a while, but Shockoe turned out to be a place where justification for that is omnipresent. Due to the nature of our business, every developer makes contributions to a wide array of codebases, and has a hand in reviewing even more. We’ll wrap up a project and deliver it to the client, who then shows it off to the rest of the company and stakeholders. Soon we get feedback… management loved it! And guess what, they want a bigger, better phase 2! This is fantastic news, but it’s time to start planning, and “bigger and better” usually means additional resources. That means bringing new developers onto the project. Getting up to speed on a project quickly is a crucial skill for us, and we want to make that transition as smooth as possible. A little extra time considering style and writing cleaner code up front could make the difference between the next developer brought on grasping it instantly or spending an entire afternoon pulling their hair out.

Every new developer at Shockoe, usually on their very first day, is invited to a repository where an internal fork of the Idiomatic.js style guide lives and asked to study it. We have eyes on each others code constantly. Every user story is a pull request that gets reviewed, critiqued, and signed off on by a coworker.

I’ve known a lot of developers to be hesitant to request stylistic changes to another’s code, and I shared those feelings once too. It can feel like you are pointing out insubstantial issues, or that style is a personal choice and you might offend them. What we need to remember is that we are all trying to improve. If another developer reviews my work and thinks “I would write this differently” then I want to hear how. Several times, seemingly minor comments or questions have sparked a discussion that roped in multiple colleagues and left us all writing better code.

So don’t be satisfied with code that gets the job done. Strive for code that actively helps the next dev down the line, that they will thank you for, because when that time comes, you could be on another project, thanking someone else in kind.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

From Hardhats to Enterprise Apps

From Hardhats to Enterprise Apps

If you would have asked me this time last year if I was going to be working for a growing application design and development firm serving fortune 500 companies – I would have said, ‘In my dreams!’

Now, I can proudly say that is a reality, and I’m still pinching myself.

A year ago today, I was inspecting residential properties, skyscrapers, factories, construction sites and pipe trenches for asbestos, lead, and mold. Believe it or not, there was a lot of downtime for this type of work in between the hustle and bustle. I’m sure you’ve seen 10 construction workers on the side of the road while two guys are doing all the hard labor. That’s called safety folks!

I was not one to sit idle in my downtime on the job site. I’m the type of person that likes to stay busy, learn and contribute to the world. Through family and friends, I learned about the ever-growing world of UX and UI design. It wasn’t long before I realized that my passion for design worked equally well in the digital world as it did in the real one – and with a couple of art degrees from my past college years, I was determined to find my next venture.

I began studying this new digital world through websites like Udemy and YouTube, which offer great lectures and tutorials. I was also turned onto Mediumspecifically the UX collection, which is full of insightful blog posts that provide a glimpse into the tech world, and some of the pros and cons of the mobile app development industry.

I spent almost a year learning from lectures, tutorials, blog posts, testing mobile apps, studying design and visiting tech fairs. By putting myself out there – I found Shockoe. I was able to get my foot in the door to prove to a fast-growing company that I had something to offer, something to contribute to be successful. 

What I’ve found most valuable working with an up and coming tech company is that they’re looking to give you a shot at succeeding. If you have the right attitude and perseverance to prove that you can contribute to the larger picture, are willing to learn and adapt and believe in high quality apps that are well thought out and intuitive, then you can find great opportunities. This is the core belief in creating enterprise apps at Shockoe. I can tell you one thing, sitting idle and watching time go by will likely keep you out of the tech world and farther from your fuller future. Instead, pull out your phone and enjoy critiquing what you love most about your favorite Android and iOS apps. 

Since I’ve been working at Shockoe, I’ve learned a lot about working as a team and how important transparency is among our peers so our ideas and our skills can be utilized appropriately or improved upon. We are creating positive user experiences by listening to our clients, thorough testing and well thought out designs with the user and their tasks in mind. If you’re ready to be apart of a team of hard workers looking to improve the world, look no further. Shockoe needs great minds like you to bring your vision to the world of mobile enterprise app development.

Start watching videos on YouTube and reading to learn what makes a great UI or exceptional UX (or even what those acronyms mean). Ask yourself, what works well and what might you do to improve them? You could be the one to join our team and create the next best idea.

Energetic designer seeking long-term teammates

Energetic designer seeking long-term teammates

Me: Designer at a fast growing, Richmond-based mobile startup seeking long term relationship with boundary pushing, continuously learning designers.

You: Talented, eager individual looking for an opportunity to design alongside a team that has your back, for a company that thrives on their employees creating innovative solutions to everyday problems without it feeling like the daily grind.

I know you’re out there. I’ve seen your work. Whether it was a pixel perfect website, an awe-inspiring app screen or a sweet icon animation, I recognized your talent and want to work with you. Let me break that down:

 

Daily designer life at Shockoe:

As you enjoy your stroll through Sketch and gaze upon the user interface you have created, relax by nudging an object a few pixels in order to align your content. Let the curves of lorem ipsum fill your thoughts and focus on the best way to apply your layout skills to perfect every aspect of a user’s experience. You may be tapped on the shoulder by a fellow designer and asked for your (sometimes brutally) honest opinion, or pulled into a white board / or sticky note session. All of these moments will culminate in a project that you can be proud of when it goes into development. You get to own every aspect of your projects, from icons to colors, interactions to transitions, from client kick-off meeting to app store launch. You will work with the team at Shockoe to deliver an innovative, amazing product that keeps the user experience at the forefront.

Sounds like a dream, right. While some days may be tougher than others, in all I’ve found Shockoe to be a rare breed of startup that not only has core values but actually encourages their employees to live by them.

While the title UI /UX designer may be intimidating, don’t let that keep you from applying. Our designers have all started as pencil-pushing, layout changing, CSS editing designers. As long as you are willing to expand your knowledge by diving deep into iOS and Android Guidelines, I believe your talents and our projects will be a match made in heaven.

Profiling Titanium: Getting a picture of the Kroll toll

Profiling Titanium: Getting a picture of the Kroll toll

As cross-platform developers, we all know that maintaining speed in a complex codebase is of paramount importance. When you’re adding layers of abstraction to your code in hopes of being able to share large portions of it across disparate platforms, the little steps you have to take to synchronize your common code with the underlying platform-specific code can quickly add up to a massive slowdown that leaves you with an application that performs and feels no better than a mobile web application plopped into a WebView.

The Kroll Bridge

Titanium effectively acts as a three-tier framework. At the lowest level, there is a layer of native code used to implement core application functionality. These are your views, your HTTP clients, and your other pieces of code that reach out and allow you to interact with device features like the camera and geolocation service. On top of these platform-specific native layers lies a platform-specific bridging layer, which allows you to abstract away the complexity of these native objects and translate them into Javascript-land objects (called proxy objects). Finally, on top of this bridging layer lies your application-specific Javascript code, which is where the bulk of your application logic will reside.

 

Titanium’s abstraction and the bridging layer is known as the Kroll Bridge, and it represents the single biggest bottleneck in a Titanium application. The Kroll bridge is exactly what it sounds like, it’s a connection between the native objects in your application provided by the Titanium SDK and the Javascript proxy objects that stand in their place within your Javascript code. Every time you update one of your proxy objects, the Kroll bridge gets to work synchronizing your changes to the native object. Because of this automatic synchronization logic, it’s easy to make a huge number of Kroll calls without really recognizing what you’re doing, which leaves you with an application that has no obvious performance issues (from a code perspective) that has distinct slowdowns when placed on a physical device.

Acknowledging the Kroll cost

Titanium provides various methods of sending data back and forward between your Javascript code and your native code. For the most part, these can be divided into the categories of bulk operations vs sequential operations. Going into this blog post, I had intended to write at length about the virtues of batching your calls and minimizing your Kroll crossings, however, it seems like there may be more nuances to the performance concerns in Titanium than I had thought! For the purposes of this blog post, I’ve taken a look at how long various operations block the Titanium thread.

I’ve prepared a couple of minimal test cases, with built-in timestamping and simple profiling code, so feel free to test these cases on your own devices! For each of these tests, we’ll run some operation 1000 times and take the difference in milliseconds between the start of the operations and the end. Note that this testbed only takes a look at how long different operations tie up the Titanium thread. Many of these tests tie up the UI thread for a substantial amount of time as well and will cause the app to become unresponsive. The UI thread performance of these tests are outside of the scope of this blog post, I’d like to circle back in a few weeks and take a closer look at the UI impact of these tests as well.

I ran all of my tests on a Nexus 5 running Android 6.0 Marshmallow and an iPhone 5 running iOS 9.1. I ran six trials of each of these tests and averaged the results. I’ve published the test code on GitHub. Take a look, give it a clone, and follow along on your own devices.

Creation arguments vs Create then set

Titanium provides factory methods to create proxy objects, which allow you to interact with native objects that you may need multiple instances of. Optionally, these methods accept a creation dictionary describing its initial state. Of course, you can just make the proxy and then configure it later, what’s the difference?

var newView = Ti.UI.createView();
 
newView.top = 5;
newView.height = 40;
newView.width = Ti.UI.FILL;
newView.left = 5;
newView.right = 5;
newView.backgroundColor = 'red';
var newView = Ti.UI.createView({
    top : 5,
    height : 40,
    width : Ti.UI.FILL,
    left : 5,
    right : 5,
    backgroundColor : 'red'
});

 

On iOS, this behaves largely as expected. Creation with arguments returns a little faster than the creation followed by sets. On Android, however, in addition to being substantially slower, the creation dictionary actually slowed the creation process down!

Sequential updates vs applyProperties

Similarly, Titanium provides both individual property set APIs as well as a bulk application API. Take the following examples:

view.height          = 80;
view.backgroundColor = 'blue';
view.left            = 10;
view.right           = 10;
view.applyProperties({
	height          : 80,
	backgroundColor : 'blue',
	left            : 10,
	right           : 10
});

 

Oddly enough, we observe the opposite behavior here from view creation! Android performs as expected, with the bulk API yielding better performance. iOS, on the other hand, runs quite slowly, and the bulk API is slower than the sequential sets.

TableView population

The table structures in Titanium also provide bulk or individual modification APIs. Consider the following examples:

for(var ii = 0; ii < 1000; ++ii){
	var newRow = Ti.UI.createTableViewRow({
		top : 5,
		height : 40,
		width : Ti.UI.FILL,
		left : 5,
		right : 5,
		backgroundColor : 'red'
	});

	theTable.appendRow(newRow);
}
var tableData = [];
for(var ii = 0; ii < 1000; ++ii){
	var newRow = Ti.UI.createTableViewRow({
		top : 5,
		height : 40,
		width : Ti.UI.FILL,
		left : 5,
		right : 5,
		backgroundColor : 'red'
	});

	tableData.push(newRow);
}

theTable.setData(tableData);

 

Finally, an expected result! The bulk population API is massively more performant than the individual population API. Android is still a little slower than iOS, but that is mostly expected.

View Removal

When flushing the views within a hierarchy, you can either loop over the children array or call removeAllChildren.

var children = theWindow.children;

for(var ii = 0, numChildren = children.length; ii < numChildren; ++ii){
	theWindow.remove(children[ii]);
}
theWindow.removeAllChildren();

 

Another API that performs differently on iOS vs Android. On iOS, the call to removeAllChildren is almost immediate, whereas on Android the call takes even longer than looping over the entire child list and removing them individually.

Event Firing

Titanium exposes a built-in eventing API used for communicating between native code and Javascript code. Additionally, Backbone exposes an eventing API for communication between Javascript objects. I frequently see the Titanium eventing API repurposed for use in Javascript-land communication, let’s see what the impact is.

var startTime;

var handledCount = 0;

function testListener(){
	handledCount++;

	if(handledCount === 10000){
		var endTime = new Date();
		var delta = endTime - startTime;

		alert('fired 10000 Ti.APP events in ' + delta + 'ms');

		Ti.App.removeEventListener('testEvent', testListener);
	}
}

Ti.App.addEventListener('testEvent', testListener);

startTime = new Date();

for(var ii = 0; ii < 10000; ++ii){
	Ti.App.fireEvent('testEvent');
}
var startTime;

//since events fire asynchronously, we need to keep track of how many were handled.
var handledCount = 0;
var eventingObj = _.extend({}, Backbone.Events);

eventingObj.on('testEvent', function(){
	handledCount++;

	if(handledCount === 10000){
		var endTime = new Date();
		var delta = endTime - startTime;

		alert('fired 10000 Backbone events in ' + delta + 'ms');
	}
});

startTime = new Date();

for(var ii = 0; ii < 10000; ++ii){
	eventingObj.trigger('testEvent');
}

 

Another substantial difference. Backbone events perform consistently (and impressively well!) on both platforms, whereas Titanium events are much slower on iOS, and are a little slower on Android.

Takeaways

The clearest takeaways from these tests are that one needs to be much more careful while modifying the view hierarchy on android, that Ti.App events are quite slow, and that there isn’t a one-size-fits-all performance solution for Titanium. There’s no magic bullet that you can adopt in your codebase and not have to worry about platform-specific performance issues. Android’s slowness when handing creation dictionaries and iOS’s aversion to applyProperties makes it more difficult to write platform-agnostic performant code. That being said, in the general case, applyProperties is still worth using, because of the small performance hit we took on iOS and the performance bump we get on Android (which is usually the issue from a performance perspective).

At the end of the day, there’s no substitute for profiling your application and making use of the platform-specific Alloy preprocessor directives (OS_ANDROID, OS_IOS) to deal with platform-specific performance issues. And now that we’re armed with concrete data, we’re ever so slightly better equipped to do that!

Course 491 – The first Cross Platform App with Design on Your Mind

Course 491 – The first Cross Platform App with Design on Your Mind

So, you’ve got a great idea but you need some help. iOS, Android, Windows, Web? Smartphone or Tablet? What platform and device should you focus on when building your first app? While I can’t answer that for you, I know there are tools that can help along the way, and that was the first topic we focused on this week.

Start by downloading the necessary tools so you can follow along, don’t worry they are all free, as long as it is for personal use. Once you are all set up, lets build your first app. We will call it the “Click Here App”.  If you are unsure as to what tools you need, check the helpful link section of this blog, but its always helpful to start at the Appcelerator Quick Start Site

Now, open Titanium on your Mac (For PC users, your first step is to buy a good hardware! I am kidding, but seriously do yourself a favor)

VCU_Week 2

Select “New Mobile App Project” and then select “Alloy” and “Two Tabbed Alloy Application”.

VCU_Week 2b

  1. Project Name: Give your app a name
  2. App ID: Reverse domain notation, you will need to use your own domain to deploy the app, but for now you can use anything.
  3. Deployment Targets: Lets focus on Android and iPhone for your first app, make sure these are selected and the rest are unselected

Lets start by changing our first files: index.xml, index.js, and index.tss

  1. In the first file, index.xml, you will add the following code:

<Alloy>

     <TabGroup>

                            <Tab title=”Tab 1″ icon=”KS_nav_ui.png”>

                                                   <Window title=”Tab 1″>

                                                                          <Label id = “Label1” onClick = ‘onTestClick’>Click Me</Label>

                                                   </Window>

                            </Tab>

                            <Tab title=”Tab 2″ icon=”KS_nav_views.png”>

                                                   <Window title=”Tab 2″>

                                                                          <Label>My Text</Label>

                                                   </Window>

                            </Tab>

     </TabGroup>

</Alloy>

In this file, we will focus on three things: (1) Assigning an ID for our Label; (2) Assigning a function to the Label; and finally (3) Changing the name of the field Next, lets update index.js; warning you will be adding your first function to the app

function onTestClick(evt) {

     alert(‘Hello Window 1’);

}

$.index.open();

Function, what?!?!  You just built your first function.

Now lets add some color, lets change the index.tss file. Its only two changes: Updating the label name and the label name color, lets make it orange, like Shockoe’s Logo

“Window”: {

     backgroundColor: “#fff”

}

“#Label1”: {

     width: Ti.UI.SIZE,

     height: Ti.UI.SIZE,

     color: “orange”,

     font: {

                            fontSize: 30,

                            fontFamily: ‘Helvetica Neue’

     },

     textAlign: ‘center’

}

VCU_Week 2c

There you have it, your first Titanium App for two platforms: Android and iOS. Your last step is to run it on the simulator. Lets run our first app on an iPhone 5s. Make sure that device is selected before you run your app.

VCU_Week 2d

Now that you are ready, lets talk design. Lets start with basics, but log in next week as we go into details. Lets start with basic design fundamentals to keep in mind:

  • The UI should be clear enough to help people interact with content; not compete with it
  • Text, Images, and Icons should be clear and legible at every size (Make sure to follow the guidelines)
  • Functionality should motivate the design
  • Visual layers and realistic motion are important to increase users understanding
  • Make sure you design for all devices and modes to make users enjoy your content

Apps don’t come with user manuals, but devices make it very easy to delete an unwanted app.

Some of the general design principles to keep in mind when designing your first app are: (1) Functional Design; (2) Design Consistency; (3) Feedback; (4) Real-life animation; and (5) User Autonomy

Helpful Getting Started Links:

Development Support:

  1. Titanium Studio
  2. Titanium Setup – Getting Started
  3. Xcode
  4. Android SDK
  5. Genymotion

Design Sites:

  1. Human Interface Guidelines
  2. Android Design
  3. Material Design
Page 1 of 41234