Like many of my colleagues at Shockoe, I began writing computer code in a high school classroom. However, in my case, the school was particularly advanced for its time in offering such a course, and our “computer” was a keyboard, dot-matrix printer, and a modem connection to the University of Virginia, where the actual computer occupied an entire floor of a large building. And while most of those colleagues went on a path that brought them relatively quickly to Shockoe, I spent two decades working as an attorney in New York, Seoul, and Virginia.
Now in my third year of software development I have felt particularly happy to be at Shockoe because I believe it addresses needs that I often saw during my time working as an attorney, needs that I am certain are shared by many industries.
In my experience, the following was typical of the manner in which law firms implement technology. First, the decisions are made by senior partners who, being busy with the representation of clients, have little time to keep up-to-date with what is available or most desirable in technology. This leads either to an “if it ain’t broke, don’t fix it” mentality, or an attempt to take care of the problem in one fell swoop with a package solution that may or may not fit comfortably with the way they have set up their practice. In the latter case, the acquired technology may go unused, or used only to the extent required by the firm. For example, if a time-tracking application is difficult to use, an attorney may keep track of his time on post-it notes as she always did before, then have her secretary type it all into the application at the end of the week.
In either case, what then happens is that employees begin finding their own solutions. Each attorney and his or her assistants devise their own system, piecing together hardware and applications as they see fit. Depending on their level of technological sophistication, they may, or may not, arrive at a solution that works well for them. However, this approach drastically reduces the potential for collaboration, and creates a host of potential problems, as the less technologically-adept might adopt solutions that introduce security vulnerabilities or other problems.
Although so often noted as to sound trite, an average employee today with a typical mobile device is comparable to an employee with superpowers two or three decades ago. To make the most of those powers, however, requires sophisticated solutions. This includes, of course, a focus on the possible pitfalls of any new technology. A device that allows employees to watch training videos at convenient times may also allow them to spend the working day watching Netflix. Large collections of data become valuable, and thus must be protected, not only from hackers in foreign locales, but from disgruntled or former employees. Yet while minimizing risk demands much attention, it is just as important to make certain that new technology is used to its full potential. Making one’s workforce five times more efficient is simply not good enough in a competitive business environment if the competition makes their workforce eight times more efficient.
This is what excites me about working at Shockoe, being able to use my skills to allow our clients to make the greatest possible use of the technology available to them. Apps created now increase employee productivity, streamline task performance and ensure employees have real-time data access they need for day to day exchange opposed to the opposite stagnant mentality. If this sounds familiar to you, check out our work for Financial Services Mobile Technology and contact us for any innovative ideas to help your team tackle your digital transformation with a great mobile strategy.
Dear New Client
We are so glad you have trusted Shockoe to help accomplish your business goals. We understand that for this particular project, you need to design and build a new workplace productivity mobile app for your employees. Here are some highlights of what you can expect throughout the course of this project.
Project Set up and Kickoff: The kickoff meeting will provide an opportunity for all team members to meet, review the project scope, timeline and processes, and discuss any anticipated challenges. Topics covered will include milestones and key dates, responsibilities, recurring meetings, status reporting, how we will work together, and contact information.
Discovery: Once we’re out of the gate, we will interview your stakeholders and subject matter experts to deepen our understanding of your business model and goals for this project. A Shockoe user experience strategist will lead this effort and may suggest activities such as market research, competitor analysis, identification of user personas, or a heuristic evaluation of your current application. Along the way, we will document your requirements and create user flows and user stories. Typically, a user interface designer is involved in this phase as well so the transition to design is seamless.
Design: Once we have outlined what your new application needs to do, our design team gets to work. These folks are the masterminds of creating a top-notch experience for your target audience. They start by creating mockups (wireframes) that show the key elements on each screen and how a user progresses from screen to screen. These mockups are easily transformable into clickable prototypes if desired for review by your team or to conduct usability testing with a sample audience. Beyond that, we bring your screens to life with a style guide and high-fidelity designs. Together these paint the picture of how the application will look and feel and will include actual colors, fonts, and images.
An agile-like process: Typically, at some point between the transition from Discovery to Design, we will start to employ an agile approach to the project. The goal is to share our work early and often so that you have visibility along the way. Together we can determine the right amount of upfront user experience planning that’s needed before we move into iterative sprints. Sprints are typically two week intervals where we identify an area of the app on which to focus, we wireframe it, apply the design, and build it. The sprint culminates with a demo at the end where we share our work and gather your feedback. Everyone looks forward to demo time!
Development: The scope of the project determines how many sprints are needed. No matter how many two-week intervals are involved, the process is the same and all members of the team know what to expect. Each sprint includes sprint planning, development of the relevant user stories, a day or two of testing and issue resolution, and finally, the sprint demo at the end.
Testing and launch: After the last development sprint ends, we spend a couple of weeks regression testing, which is thorough testing of the entire app to ensure that all functionality is working as expected and that there are no display issues across supported devices. Any issues identified are resolved and then the app is turned over to you to perform user acceptance testing. Fortunately, you will have had access to the app at each sprint demo when the QA version of the app is uploaded to Shockoe’s server for download. This testing at the end of the project is an opportunity to execute all test cases and confirm the final product is ready. Beyond that it’s just a matter of planning for submission to the app stores. Shockoe can either help you through that process or submit the app on your behalf.
We are with you throughout the life of the project and let you know what to expect at each step of the way. We find that by the end of a project, our collective team has bonded in a way unlike no other. We are working together to produce something that will make people’s lives better in some way. And that’s a great feeling. Thank you for letting us be a part of it.
Let’s get started . . .
The Shockoe Team
Last week I had the pleasure of attending Node Summit 2016 in San Francisco. I am eager to share some of the new cool technologies and concepts I learned about while I was there.
The one hardware workshop at the conference proved to be perfect office hackathon fodder. Particle.io is a platform for interacting with internet of things devices, and using node and their Photon microcontroller we were able to program a row of lights to act as a scoreboard for a game of tic-tac-toe. As someone who deals strictly with software, it was a welcome diversion to play around with breadboards and resistors for a few hours.
One of the most insightful and fun presentations I attended during my time at Node Summit was on security. This talk featured a lot of great examples of trying to hack into or disrupt a locally hosted web application. Of course, the main thrust wasn’t to teach people how to hack–though I can’t say I didn’t learn a thing or two–but to show how out-of-date node modules can bring security vulnerabilities to your codebase. The presentation concluded with a stern warning that actual hacking was illegal and an insight into a current company for those in need of a fix:”bugcrowd” a platform that lets companies pay bounties to hackers to break into their systems so that they can close any security gaps.
The main buzzword at the conference was micro-services. Every sponsor from NASA to Netflix gave talks on how they have transformed their entire systems over to use this architecture concept.
Micro-services are not specific to node, but node’s flexibility means that it lends itself well to the concept. The micro-service pattern refers to breaking out all of the functionality of your product into independent pieces, instead of housing them within a single unit–known as a “monolith”. This way, when you make changes to your app, you don’t have to redeploy your entire codebase. Instead you’re deploying just the parts of the app that were affected by changes. This works especially well in node because you to pull in only the modules you need for each individual micro-service, and there are tons of node modules out there designed with communication between micro-services in mind.
Looking back at the conference as a whole, I was inundated with the vastness of node itself. Every year for the past four years the numbers of new node users has doubled, and there are 300+ new modules published every day. This has inspired me to try them all out and bring cool new technologies back to Shockoe.
A little about the developer
Having been working with the Titanium mobile application framework for the better part of the last year, I have developed an appreciation for what it does and what it tries to do. Creating a true cross-platform framework that tries to do almost everything that each native framework can do and unifying those into a singular codebase is definitely a challenge, one that Appcelerator has done well. After working on several projects with the framework, I feel that my programming skills and my understanding of the mobile world have drastically improved.
That being said, I wanted to start working more in the native world to get a better understanding of what Titanium was doing behind the scenes. This led me to start exploring the native frameworks for iOS and Android. I have focused on Android as I have a decent Java background. I’ve always believed that the best way to learn something new is to just dive in and figure stuff out as you go. Thus, I decided to recreate the very first application that I worked on after starting at Shockoe. The new application was dubbed Doorman as that was ultimately it’s basic purpose. It’s meant to act as a virtual doorman for people walking into the office. After getting the API setup, I jumped into writing the code and learning more about Android.
My Impressions of Android
My initial impressions of native Android development were very good. While it did have a learning curve, once I started to get a better understanding of activities, intents, services, etc it was a breeze to work with. It did miss some of the libraries that Alloy had access to like Moment, Underscore, and Backbone but I learned to work around them. Probably the most noticeable difference in the Android world coming from Titanium was the sheer amount of developer support found on the web and documentation. In addition to the amount of documentation put out by Google, the number of Stack Overflow posts with developers having similar problems really helped me with detailed explanations and examples from responses. It was indeed a breath of fresh air for a new developer just starting to get their feet wet. Even working with third party libraries was simple as they were optimized to work within the Android environment and I could use them directly rather than having to create a separate module to link the two together. Appcelerator did have a lot of detailed documentation that I heavily relied on, especially when working on the already existing codebases that used components and proxies with which I wasn’t very familiar. However, there were times when I ran into an issue that I couldn’t resolve with the documentation. The fewer number of developers post on internet made it more difficult to find a resolution if my fellow Shockoe developers couldn’t help me.
Setting up Jenkins
Once I was comfortable enough with the state of the application and API that I felt a test build was necessary I moved over to work with Jenkins, our build environment. Initially, I was a bit nervous about getting the build setup. I hadn’t yet built the application through the command line but instead was using Android Studio. As it turned out, it was a very simple process to get the builds created and uploaded after some research into Gradle, a fantastic build tool for Android applications. With just two shell commands I was able to build the application and get the .apk file to send to AppTracker, our in-house distribution service. I was amazed how easy it was to get setup. However, it didn’t take long for me to realize that the app was showing errors when trying to install on a device. Turns out that I wasn’t signing my apps before uploading them. Oops. Again, with the help of the large number of Android developers on Stack Overflow, I was able to determine that I needed to adjust my Gradle scripts a bit. I just needed to link a .keystore file to the Gradle build command then bam, signed .apk files to upload to AppTracker. The app was then ready to install on device.
Overall, I really enjoyed the experience working in the native world. I learned a lot about the what is going on behind the scenes when developing Titanium apps. I believe that this understanding will help me to become a better developer going into the future. While I know that Titanium won’t be going away anytime soon as it is a great tool for creating quality applications and a relatively small time frame from not having to create and maintain two separate codebases, I would love to continue learning more about the native world.