Posts by Ryan Carlson

Ryan Carlson
Ryan Carlson

Ryan is a veteran of electronics manufacturing, custom software development, promotional marketing and is a thought leader in the customer loyalty software industry. Joining The Nerdery in 2012 as a Solutions Engineer, Ryan brings his knowledge and technical expertise to The Nerdery’s marketing department as the resident Technology Evangelist. Ryan is the host of The Nerdery’s weekly podcast, editor of the Nerdery Blog, regular speaker, and is a contributing author for Wired.com and GeekDad.com.

Developing PHP Developers: The Many Special Talents of Jansen Price

NerdCast

We are joined this week by Jansen Price, a Principal Software Engineer (big kahuna of PHP) from The Nerdery. He shares a unique perspective on how we handle ongoing education and facilitate growth as developer. He talks about the book he is writing about learning object-oriented languages and what it takes to learn new things.

Easter Egg: The intro and outro music is performed by Jansen and his mad beat boxing skills.

Episode: #94

Host:Ryan Carlson

Guests: Jansen Price - Principal Software Engineer (PHP)

Listen Now: Running Time: 0:21:43 / Subscribe on iTunes

Play
Filed under NerdCast

The Evolving Technology of Social Media

This webinar explores the technology behind the tools businesses and community managers are integrating into their software platforms. This is not a discussion about which key words resonate best with an audience or optimal word counts. Nerdery developers and social media integration specialists Thomas McMahon and Doug Linsmeyer  describe the software options typically leveraged on social media software integrations. Our audience gave feedback that anybody could follow this conversation, regardless of their technical level. Social media consultants, account managers, and anybody seeking an understanding of the tools and technology going into today’s social media integrations will find this discussion useful.

Slide Deck: To view the slide deck you can visit our Slideshare page.

Bonus Q&A Podcast: (running time 9:22)

Our panel of experts follow-up with three of the  interesting questions from our live audience that we didn’t have time to address during the webinar:

  • Are location-aware tools like FourSquare still worth considering?
  • Possible technology solutions to promote a mobile business.
  • The different social platforms and how they differentiate, and more.
Play

Oculus Rift Experiment – Is Virtual Reality Ready for Business Applications?

Introduction to Oculus Rift

The Oculus Rift is a new Virtual Reality (VR) headset designed to provide a truly immersive experience, allowing you to step inside your favorite video game, movie, and more. The Oculus Rift has a wide field of view, high-resolution display, and ultra-low latency head tracking unlike any VR headset before it.

Nerdery Lab Program: Oculus Rift

Nerdery Lab Program

Lab partners Chris Figueroa and Scott Bromander collaborated on this Oculus Rift experiment; their respective Lab Reports are below. The Nerdery Lab program is an opportunity for employees to submit ideas for passion projects demonstrating cutting-edge technologies.  Nerds whose ideas show the most potential are given a week to experiment and produce something to show to other Nerds and the world at large.

Lab Report from Nerdery Developer Chris Figueroa:

How is the Oculus Rift Different from other Virtual Reality Headsets from the past?

The first thing to know is the Oculus Rift has very wide range. Previously you would put on a VR headset and have tunnel vision. It didn’t feel like a you were in the experience. This was critical because its called “Virtual Reality.” How can you feel like you are somewhere else if you just feel like you are watching a tiny screen inside of goggles?

Oculus Rift puts you in the virtual world. You have a full 110- degree field of view, which has never before been used in Virtual Reality. When you put on the Oculus Headset you immediately feel like you are in the virtual world. You actually look up and down and can just move your eyes slightly to see objects to the left and right. One of the key things about the Oculus is you have peripheral vision, just like in real life.

Rapid Prototyping at its finest

The first thing you always do is get a sense of what the 3D world will feel like. Put placeholder blocks everywhere – blocks in the size of the objects you will later put there. For example, the blocks you see below became a rocks. We placed a block there so when we put the VR headset on, we’ll know there will be something there.

oculus1

oculus2

Development Challenges

Developing for the Oculus Rift is a complete departure from developing video games, 3D movies, 3D graphics or any sort of media that involves 3D. You’ll quickly realize that things you create are making people sick with the Oculus Rift. Sometimes you won’t know what is making you sick – you just know something “feels wrong.” It’s a dilemma to have a very cool product that makes users sick because something on the screen moves wrong, or the UI is in their view or textures look wrong in the 3D world – it can be any number of things. Below is what we encountered.

1. Don’t Be Tempted to Control Head Movement

In real life you choose to look at something. Advertisers have experience in making lines a certain way with colors that guide someone’s eye to an object on a billboard, but with Virtual Reality you have to do that in 3D space. It has a whole new element of complexity that is unheard of and very few have experience in.

The easiest thing to do is just move the 3D camera so it points at something. What you don’t think about is that no one in real life has their head forced to look at something, so if you do it in Virtual Reality it literally can make people sick! It’s just ill-advised to make users ill.

2. User Interface vs World Space

The Oculus Rift wants you to feel like you’re experiencing real life. So how do you display information to users using the VR headset? The first thing people say is “Lets just put information in the top-right corner to indicate something important needed to get through the experience.” This sounds completely normal and works for everything except Virtual Reality – putting something in the view of your face will not only obstruct the view of the user – it could also make them sick!

Rule of thumb that I learned from the Oculus Rift Founder:

“If it exists in space, it doesn’t go on your face.”

3. Development Kit Resolution

The first development kit for the Oculus Rift has very low resolution in each eye. When people first put the headset on they will immediately say it’s low resolution. They are right and it was very interesting to work with because 3D objects and their edges, colors and lines don’t look the same as they do on your computer screen. Sometimes fonts are completely unreadable.

Everything must be tested before a user tries the experience or they may miss out on whatever the 3D world is attempting to show them.

4. High Resolution Textures vs Low Resolution Textures

Most people that work with 3D content or movies without restrictions know that higher resolution is better. The low resolution of the Oculus Rift made for some weird problems because higher resolution textures looked worse than low resolution textures. Even though people can look at a 3D rock and know its texture is low resolution, it didn’t matter because the high resolution textures didn’t look anything like what you wanted them to be.

Programs I used for the Oculus Rift Project:

  • Unity3D – Game Engine used to interact with 3D environments
  • Oculus Rift Dev Kit 1
  • C# and C++ (Oculus SDK)
  • MonoDevelop – I write C# on a mac with Unity3D
  • Blender 3D 2.69 with a python transform plugin I made.
  • Photoshop CS6

Lab Report from Nerdery Developer Scott Bromander:

Building 3D Modeling for the Oculus Rift

The process for this lab experiment was broken into two clear paths of work. The 3D modeling and SDK (software development kit) engine work could happen simultaneously since we had to have 3D visual assets to actually put into the environment, much like drafting a website in Photoshop before slicing it up and styling with HTML and CSS. The Oculus SDK focused more on the environment and user interactions, and I took placeholder objects in the environment and added in the realistic assets.

For my specific portion of this experiment, I handled the modeling of objects within the 3D experience. Since our goal was to create an example of a business application for a 3D simulator, I built a full-scale model of a residential house. Our experiment demonstrates how Oculus Rift could be used in visualizing a remodeling project, vacation planning, or property sales.

Building these real-world objects is a lot like sculpting with a block of clay. You start with nothing and use basic geometry to shape the object you would like to create. In this case, it was a house that started out looking very plain and very gray.

Typically in the 3D modeling process, the real magic doesn’t come together until later in the process – you change the flat gray 3D object and give it a “skin,” called a texture. Texturing requires that you take that 3D model and break it down into a 2D image. Creating 3D objects follows a specific process to get the best results.

My Process

Plan and prep; build a pseudo schematic for what would be built; create a to-scale model; texture/refactor geometry.

Tools

I used 3D studio Max to build out the front of the house, and I used measurement guides that I pre-created with basic geometry – in this case, I used a series of pre-measured planes for common measurements. I was able to then use those guides throughout the modeling experience to speed things up.

Additionally, I used a lot of the data-entry features of 3DS Max to get exact measurements applied to certain components of the house. This ensured that the scale would be 100% accurate. Once it was modeled in 3DS Max to scale, we then came up with a conversion ratio to apply before bringing the model into Unity.

Finally, we optimized texture maps by including extra geometry for repeating textures (like in the siding and roof). The trick here was to plan for it while at the same time ensuring the scale was accurate. In this case, guides help a lot in slicing extra geometry.

Photoshop for texture generation

To create textures for the house, we used photos I snapped from the first day. One problem here: I  didn’t set up the shot for texture use (lens settings), so there was a significant amount of cleanup work that needed to be performed. If you think about how we see things and how a lens captures images, it’s not in a flat space but rather a little more spherical. So using a combination of stretching/clone stamp/healing-brush techniques I’ve learned over the years, I was able to take this semi-spherized image and make it appear flattened-out.

After those textures were created, we took a pass at creating bump and specular maps. While the final product of that work ultimately never made it into the final experiment, I did follow the process. In both cases, I used an industry-standard tool called Crazy Bump. The purpose of these types of “maps” is to create the look of additional geometry without actually adding it. Basically, these maps tell Unity how the light should respond when hitting the 3D object to give the effect of actual touchable texture. So if you get up close to the siding, for example, it has the ridges and look of real siding.

Had we more time, we’d have used Mental Ray texturing/lighting to give a more realistic look, and then bake that into the texture itself. This effectively would’ve taken all of these different maps/texture/and lighting situations and condensed them down into one texture. Next time.

Challenging Aspects

One of the challenging aspects of this project was adding the actual geometry from the early designs based on “what is important” vs. using a texture. My initial thought was that if I was able to get close to these objects with the Oculus Rift on, I’d be able to catch a lot of the smaller details – planning for that and getting a little deeper in the geometry was on my radar from the get go. Ultimately though, with the prototype version of the Oculus Rift having a lower resolution than planned for final product, a lot of those details were lost.

Objects like the window frames, roof edging, and the other small details were part of the early process. You save a lot of time when you do this planning up front, but it’s more time consuming to make particular changes after the fact. While it doesn’t take a lot of time to go back and add those details, knowing their placement and their measurements ahead of time really smoothes the process.

New things that I learned

Important lesson: How to plan for the Oculus Rift since it doesn’t fit into the usual project specifications. Having a higher polygon count to work with was freeing after several years of building for mobile and applying all of the efficiencies that I’ve learned as a result of creating performant experiences for mobile. But I learned this maybe a little too late in the process, and it would have been great to include those in my initial geometry budgets. Ultimately, the savings helped us when it came time to texture. All of this is the delicate balance of any 3D modeler, but it was interesting being on the other end of it coming out of modeling 3D for mobile devices.

Things I’d have done anything differently in hindsight

I would have shifted my focus and time from the small details that didn’t translate as well, given the lower resolution of the prototype Oculus Rift that we were working with. I could have spent that time creating bolder visuals and texture maps.

Given more time, or for a next iteration or enhancement that would make for a better or more immersive experience, I’d also create more visually-interesting texture maps, build out the interior of the house, and add more tweeting-style animation – including more visually-interesting interactions within the environment.

I’d like to have spent less time on the details in the 3D-modeling portion and spent a lot more time getting the textures to a place that were vibrant and visually interesting within the setting that we ended up with. In any rapid 3D-model development, one needs to remember that it starts as a flat gray model. If you don’t plan to take the time and make the texture interesting, it will look like a flat gray 3D model. So having more time to go after the textures using some sort of baked Mental Ray set-up would have been awesome.

Which really brings me to what I would love to do in another iteration of the project: Take the time to make textures that look extremely realistic, but doing so in a way that utilizes the strengths of the Oculus Rift and the Unity engine – which can all be a delicate balance of texture maps between 3DS Max and Unity, in conjunction with how it renders in the Oculus Rift display. I think that would drive the “want’” to interact with the environment more. Then, beyond the model, include more animation and feedback loops to the interaction as a whole.

I’d also include an animated user interface – developed in Flash and imported using a technology like UniSWF or Scaleform – that would be used to make decisions about the house’s finishings. Then, as the user is making those decisions with the interface, I’d include rewarding feedback in the environment itself – stuff like bushes sprouting out of the ground in a bubbly matter, or windows bouncing in place as you change their style. Or that sort of thing – the type of interaction feedback we are used to seeing in game-like experiences, but instead are using it to heighten a product configurator experience.

Again, next time – so that’s our Lab Report for this time.

Maintaining Your Software For The Long Haul

In our webinar on maintaining software maintenance we discuss the importance of having a plan. Part of this plan is identifying and addressing the root causes of an observation, not just treating the symptoms. So, taking our own advice, we address the typical root causes of needing software maintenance. We specifically call out how we all make decisions in software development that will have an impact on the short-term and long-term lifespan of the project. This is how we define technical debt. Tune in to the webinar for a great conversation that can give you the context to better understand long-term support of a project.

View the Slides of this webinar on our SlideShare Page

Listen to the Q&A audio recording below:

(Running time: 13:15)

Play

Your Users are Yip Yips

Using UX tools to serve all your users. Yip, even the plush aliens.

By Emily Schmittler and Christopher Stephan, Senior UX Designers

As UX designers, we always want people to understand, benefit from and even enjoy the designed interfaces and experiences we’ve shaped for them. The clients and companies we work with feel the same way; however, where we often differ in approach is in how we do the work to get there. To many UX professionals the appropriate process involves engaging with and talking to members of the target-user population. Many companies assume the UX professionals they hire have built-in knowledge about their audience and don’t think spending time with users is necessary.

This thought – that we in UX have users “all worked out” – is a frequent cause for concern. Sure, we can perform expert reviews and analysis, we have principles like Fitt’s Law and “7 (+ or – 2),” and an often involuntary strong gut reaction to interfaces that are not as clear as possible. However, no set of models, rules, guidelines or physical reactions can ever effectively approximate a single human being, let alone any group of them. Humans are unpredictable, frustrating, willful and sometimes hilarious. In short, your users are Yip Yips.

Photo of two Yip Yips

These are Yip Yips. Yip yip yip yip uh-huh uh huh.


How are Yips Yips like users?

You’re likely wondering what comparison we can make between your customers, subscribers, visitors and contributors to bug-eyed, plush alien rags with a lot of mouth that sound like ⅓ of every corporate teleconference you’ve likely ever witnessed. For that you’ll have to journey with us beyond the puppets to the puppets’ behavior. Lets take a closer look at Yip Yips.

They’re not from around here

Yip Yips are aliens from a different planet. They are not like you and they do not respond how you might expect. Users don’t come from planet YourOrganization. And just because you think your instructions are straight-forward and your meanings plain, they might not mean anything to a creature from outside your intellectual ecosystem.

Their background and understanding is not like yours

Yip Yips don’t have your frame of reference, your cultural history, your idioms, jargon or catch-phrases. This means they cannot be expected to perceive your world in the same way as you, talk about it using the same words, or approach things in the same way.

They are smart and learn from their experiences

The Yip Yips are examining our world and forming reasonable intelligent opinions based on their experiences. This means that they are not passively consuming what they see and hear. They’re finding ways to understand and engage. Users are also going to – consciously or not – try to understand your offering and message. They will make connections and meaning that are sensible and relevant to themselves.

They have goals and came for a reason

While not trying to actively conquer earth – so far as we know – the Yip Yips do seem to be here to learn. They are driven by curiosity and the need to learn and understand. Your users are going to have goals, too. Like the Yip Yips, we can’t be certain what caused them to visit or engage.

5 Things Yip Yips Teach Us

(In their own special way)

Some of what you are about to see you may have seen before. Not on PBS, but in the behavior of your users. While most of your users are likely not covered in colorful plush fur and have fewer antennae, they still do what can seem to be strange, random and unpredictable things.

Yip Yips Discover Earth

While the Yip Yips didn’t find Earth – their intended target – right away, they did learn a few new things during their exploration.

Lesson 1: A user’s experience is about the journey as well as the destination

In the process of looking for Earth, each new discovery was exciting and educational, making their experience an overall positive one. Users may not always know exactly what they are looking for, so it is important to identify what they find valuable, useful and entertaining to make sure that their journey is always positive. While you might have your main navigation nailed to perfection, users may need more to engage them and keep them returning to your site or application.

Your Project: The user who doesn’t know what they are looking for is just as important to the success of your design as the one who does. User research and an understanding of their behaviors can help determine how to support exploration and playfulness in these less-directed individuals.

Lesson 2: It’s good to be challenged, in some cases

Not everything has to be easy. Again, pointing to the fact that the Yip Yips enjoy their journey to finding Earth even though it isn’t successful immediately demonstrates the joy individuals often find in being challenged. Commonly, clients misconstrue UX to be about making things “easy to use.” Au contraire! A challenge can make experiences more enjoyable than something that is perceived as easy. Consider the design of a game. Are easy games fun? Not really. Therefore, UX plays a very important role in determining level of challenge that proves engaging. In these cases, it is essential to determine an adequate level to ensure the offering isn’t so difficult that it’s frustrating – or so easy it gets quickly discarded as boring by consulting users via testing.

Your Project: It’s okay to make things harder for a good reason. Just not too hard. Usability testing is a great way to test concepts that need the appropriate amount of difficulty.

Yip Yips Discover a Clock

Lesson 3: Even a detail can scare people away

Another common misconception about user research is that it’s nothing more than asking users what they want. In this example, the Yip Yips are presented with a clock. The clock has all the attributes they were expecting; however, it still scares them away resulting in an overall negative experience. While user research may seem aimed at discovering what users want, it more importantly uncovers why they want it – allowing the designer to make educated decisions on whether the requested feature is appropriate – and what would make the experience useful. Therefore, we employ research methods to get at the core of what users are experiencing so we can address the problem instead of offering temporary relief of the symptoms. Further, we test those ideas with those users to ensure that the intended outcome is met.

Your Project: Don’t focus discussions with users on what they want, instead talk about the problems they are facing to understand their viewpoint. Use the problem space to inform design decisions, then test for success.

Yip Yips Discover a Radio

Lesson 4: Users might not want what you’d expect

In this case, you could make the common-sense assumption that people have preferences for certain genres of music, but overall the experience of music is pleasant. The Yip Yips prove that a general understanding – or a common sense approach – is not enough to design an experience that is inherently pleasant. What if – like the Yip Yips – your users have totally different preferences than you would expect [and would rather listen to static]? This is a more common occurrence than you might expect.

Your Project: It is extremely important – especially with new product concepts – to research and test ideas with real users before making a large investment to develop an idea. By involving users, you can more easily determine worthwhile features more quickly. There are many ways to involve users in the design process that go beyond asking what they want. Consider collaborative design sessions with your users, or methods that look at the problem space in a broader sense, like observation.

Yip Yips Discover a Fan

Lesson 5: Engagement doesn’t mean positive experience

Ever look at your site analytics and think, “Wow! People are spending a lot of time on our site. That’s great!” Unfortunately, you may be misreading your data; however, there is no way to prove it without diving deeper. In this video, the Yip Yips demonstrate how a user can be (or appear to be) engaged, but have a totally negative experience anyway in that they are blown across the room… twice!

Consider that sometimes users are obligated to use a system. Signing up for insurance, using a website for work, doing taxes are all examples where a user has a task that they must complete; therefore, they are likely to spend more time painstakingly interacting with a system they may have otherwise ditched when the unpleasantness began. In these cases, the analytics may look as if a user is engaged, but that’s not necessarily the whole story.

Your Project: Even if you have really robust analytics data that suggests positive or negative experiences, it is really important to dive deeper using qualitative research methods to ensure a successful redesign.

An Ecosystem Full of Yip Yips

So if users are like Yip Yips, what does that mean for how we think about users? It proves that we should be watching them a little closer, and trying to understand their motives or support their interests. Luckily, UX designers come primed with tools and methods to help you build that understanding and define where the overlap between business goals and user needs lie. And, you don’t necessarily need to spend a fortune to do it. We can help you to better know your Yip Yips in a variety of ways within your budget.

Next time…

Now that we’ve told you why you need to think of your users as Yips Yips, stay tuned for some ideas about how to do research with your users, and how to test the designs that your research has informed. Watch blog.nerdery.com for part-two of the Yip Yip adventure!

Filed under Design, The UX Files

Webinar: Mastering Interactive Development Lingo

Due to unfamiliar and sometimes confusing  language, interactive projects can end up costing more or take longer to complete than they were supposed to. One of the primary contributors to project delay is a result of what we like to call the “Miscommunication Tax.” In this webinar we took the opportunity to talk through some of the lingo that consistently lends itself to miscommunications during a development project. If you are selling interactive projects, working on interactive projects, or would like to hear what a user experience designer, a developer, and quality assurance engineer have to say about confusing terms and how to create clarity around them, you’ll want to tune in.

Bonus Content:

Filed under Nerdery Webinar

NerdCast #91: Webinar Q&A – Mastering Interactive Development Lingo

NerdCastIn response to our recent webinar about development lingo we have conversations about how to avoid paying the high price of what we call the “miscommunication tax”. Curious to learn more about what goes into a Scope of Work? Where most of the confusion occurs within a project plan? What about Quality Assurance runs into the most resistance? These are the kinds of questions we answer in regards to learning interactive development lingo.

Host: Ryan Carlson

Guests: Josh “Paro-like-arrow”, Sherman Bausch, and Justin Holman

Listen Now:Running Time: 0:21:25 / Subscribe on iTunes

Play
Filed under NerdCast

NerdCast #90: Building Upon Great Solutions With Java

In this episode of the NerdCast Brian Rowe interviews Nerdery Java developer Sarah Olson and he asks the all important questions, “What would you say ya do here?”. They talk Java, new frameworks, the pending release of Java 8 and much more.

Host: Brian Rowe (UX Manager)

Guests: Sarah Olson (Software Developer)

Listen Now: Running Time: 0:21:25 / Subscribe on iTunes

Podcast Transcript:

S1 00:00 This is the NerdCast, building upon great solutions with Java. I’m Brian Rowe, UX manager here at the Nerdery. And today, I’ll be having a fantastic conversation with one of our Java developer extraordinaire, Sarah Olson. She gives us a great rundown on where she comes from, how she got into Java, what she does here at the Nerdery. She touches on some interesting technologies and assistance in the Java world, like Play, Scala. We talk a little functional programming and what’s on the horizon, potentially with Java 8. Stay tuned. It’ll be fantastic. You don’t want to miss it. This episode is brought to you by the Nerdery, a developer driven, interactive production company that specializes in custom software development and user experience design. It’s been voted by its staff onto numerous top workplace lists. And they have offices in Minneapolis, Chicago, and Kansas City. Developers, designers, and other aspiring nerds can learn about joining our team online at nerdery.com/jobs.

S1 01:01 Thank you, everybody for joining us here at the Nerdery today. I’m Brian Rowe. I am UX manager. I’ve served several purposes around the Nerdery in my time. But today, I have the lovely pleasure of having a conversation with Miss Sarah Olson, one of our esteemed Java developers here at the Nerdery. So Sarah, thank you very much for joining us today.

S2 01:19 Thank you.

S1 01:20 I wanted to have this conversation because– Well, in part, I know our audience is going to be very interested in what our Java devs do here. But also having some of that background myself, I’ve been curious too as to the adventure a Java dev takes once they joined the Nerdery. Just to get things rolling, what I’d love to hear is a little bit about what you actually do here day to day.

S2 01:46 Day to day, we’re typically working on– With Java, we’re working with larger clients, usually. We’re working with clients that are more typically enterprise or corporate level. Some of the larger clients out there are the ones that are using Java for their enterprise. It runs the gamut from small web apps to really large web apps. Sometimes we’re doing more of a support-based project, where we’re bringing in existing code. Other times, we’re creating something from scratch. Sometimes we get to use some of the newer technologies. Play and Scala is one of those latest ones I was working with. But a lot of times, the clients are the ones who are dictating the technologies we’re using, so a lot of it depends on our clients. And we can jump in to learn technologies that we don’t necessarily know right off the bat. So being able to pick up new technologies is pretty critical for our Java devs.

S1 02:59 Absolutely. Obviously, some of that– Even if you’re doing more open-ended work, creating this thing from scratch – like you’ve said – there’s probably within a larger enterprise client plenty of other systems that they need these things to hook into that probably help dictate some of that stuff that you need to do. Cool, so you mentioned a couple of things, Play and Scala. So for those of us who don’t know what those are.

S2 03:22 Play is a framework that is good for REST-based web applications. So it’s a way of implementing an application more as a rapid development framework, where you can get things up and running really quickly. Scala is a language that runs in the JVM. So it’s like Java, but more on the functional programming side.

S1 03:54 Interesting.

S2 03:55 So, it’s a mix of the two.

S1 03:57 And for the audience, REST is?

S2 04:01 REST is just a format for web applications to follow that is a best practice for APIs, which we deal with a lot here – either building an API or working with an API.

S1 04:17 It’s a little bit more semantic, right?

S2 04:19 Yeah.

S1 04:19 I request a thing, and a web browser gives me back something – human, readable, understandable.

S2 04:24 Right, it works really well with the HTTP protocol. It’s meant to really flow with that well.

S1 04:31 And then – in terms of frameworks – what it sounds like too, for those who do have more of a Java background– I had some familiarity with things like Java Struts and Struts 2. It would be something like that – in this case, Play – to allow me to basically govern what happens, step by step in a web application. And when you say web apps– just because, again, I’m curious. This is different than what we usually do. We’re not talking about necessarily building a brochure website. These actually might be what? Internal, real, full-blown business applications that just happen to be on a website?

S2 05:07 Yeah. Typically, if we’re building a brochure site, we’re going to use different technology – like PHP, or something like that. So if we’re doing Java, it’s usually because the client is already using Java and wants to continue. Usually, they’re more complex applications. And they’re connecting with multiple– other applications or systems, or an ESP, or something along that line where it makes sense to have a more robust application.

S1 05:37 Absolutely. Do you do more of the upfront work? That means anything that might be in the browser that a user is actually going to see day-to-day when they use it? Or do you do more of the back-end connections and hookups?

S2 05:52 We’re definitely more on the back-end. There is usually some integration of the front-end work that we have usually another developer do. And then, we usually come in and integrate the two. So we put in our hooks for the back-end into those files that another developer has made for us.

S1 06:15 Does this require an awful lot of back and forth with people who might be IT resources at one of your enterprise clients as well?

S2 06:22 Yeah. With the Java, we’re definitely working a lot with other developers. Whereas, the projects I’ve done in other technologies like iOS and WordPress, we’re working more with either marketing or even the end client. So it’s definitely a different client relationship with the Java side.

S1 06:44 Now, you mentioned a couple of different things that you’ve done. So how, why Java? How did you end up here doing that at the Nerdery?

[chuckles]

S2 06:53 I had experience with Java for 13 years, so I came in as a Java dev. Because we are so good here at training– in cross-training, I’ve picked up iOS and I’ve picked up WordPress while I’ve been here. But my background for the last 13 years has been Java.

S1 07:19 What are some of the key challenges that you see or face routinely now? Some of those big hurdles that as a Java developer here at the Nerdery, dealing with these kinds of clients as you described, what’s really the struggle or the interesting challenge?

S2 07:38 Typically, our challenges are working with existing technology. We don’t always get a lot of documentation on what that technology is doing or the business logic that’s being used. A lot of times, the– sometimes we have clients who are unhappy with the current system they have. And it’s working with them – especially with UX – to figure out what they actually do need. And then, trying to either work with their existing code to make it do that, or to start from scratch and rebuild in certain cases.

S2 08:17 A lot of times, we do have existing code. That makes it a little bit more complex, because we’re trying to fit things together that don’t necessarily want to go together. When we’re working with other clients, we have a little bit more freedom to do what we want when we’re working with other developers or even other vendors that this client might have. It gets to be a lot of requirements gathering, and everyone has to agree on it. And it takes longer to come to that agreement, because there are so many parties involved and they all are very technical. So it definitely requires a lot of documentation and discovery, a lot of meetings, to try and figure things out and all come to that agreement.

S1 09:14 Obviously, conversations, meetings – either face-to-face, remote, what have you. How does someone like yourself here manage to broker a lot of those interesting relationships and negotiate some of those tradeoffs? Because it sounds like, as you describe it, there are [chuckles] a lot of parties involved that might not all have the same vision in mind. But to make any of this work together, you’re going to have to come to some kind of unified idea.

S2 09:40 Going into things with a mindset of, ‘We need to do what’s best for the client or for the project as a whole.’ It gets your focus in the right spot. While we might have our own internal project that might be successful, if the entire project is not successful for the client, they’re not going to be happy. So we need to look beyond our own requirements that we have, and see the project as a big picture deal. What is going to make the client happy in the end is really what we need to be striving for. So a lot of those discovery meetings and other things are really critical for that to say, ‘I could just gather my requirements for this tiny piece that we’re doing, but that’s not going to– we’re not going to have insight into whether this whole project’s going to be successful if we do that.’ So I think that reaching beyond what we’re exactly going to be doing, and to see the whole– what is the client trying to do with this project?, really helps ensure the success of the project as a whole.

S1 10:57 Fantastic. I would assume, but maybe I should ask instead. A lot of years of solid Java development experience in your past before you joined us here at the Nerdery. Was a lot of that time spent doing something very similar? Meaning, being able to reach out and form that broader, bigger picture of what’s really required and to make something successful.

S2 11:21 I come from a background mostly working in the corporate arena. We’ve had to work with overseas companies, a lot of companies are doing outsourcing as a supplement to a lot of the local development they’re doing. There’s a lot of back and forth with that. So that helped prepare me for a lot of this work, because we’re working with other developers – especially in other countries with other time zones.

S1 11:55 Language constraints sometimes.
[chuckles]

S2 11:57 Definitely language constraints. So, I think that a lot of that really worked in my favor coming here.

S1 12:03 Absolutely. Well, I’m sure too, even just being able to communicate those requirements back out to other people that you partnered with would be very detailed, I’m sure–
[chuckles]

S1 12:11 –to avoid some of those missteps when, ‘Hey, we need this team in the Philippines to build this. They’re going to be doing it overnight while we’re working on something else.’ And trying to share what exactly you need to have happen.

S2 12:21 We’ve had clients come to us that are outsourcing a lot of their work. So we’re working with those parties here as well, or bringing in code from parties.

S1 12:31 Since you get to see it from the inside, what do you think is one of those attracting factors for an organization like that to come to us with that help? Hey, if they’ve got a ton of offshore developers, what do we bring to the table? What do you bring to the table that’s different?

S2 12:47 For the most part, the things that I’ve seen– the issues that have arisen are a lack of architecture in future consideration for where the project wants to go eventually. A lot of the projects that we’ve taken in have really have not laid the groundwork for good architecture, so they end up with performance concerns, or they can’t modify their code for new requirements. It works the way it does, but it won’t support any future work that they want to do. One of the things we do, especially with UX, is where do you want to go with this? And let’s build a strong foundation so that it can grow with you, instead of having to scrap it and rewrite a whole new app every time you want to add some additional functionality.

S1 13:38 So we’re talking about things where… again, back to how you phrased it, “this bigger picture, broader picture.” I’m trying to craft something here at the Nerdery for these people that ideally is extensible and maintainable. Someone else down the road – years on, perhaps – is going to inherit this thing. There’s going to be different needs, and they can still take this foundation that we’ve built and leverage it going forward.

S2 14:02 Yeah, and a lot of– some of the key things that we look for in Java and other object-oriented frameworks or any frameworks really is reusability. Not repeating yourself, so you have the same chunk of code in multiple places and things like that. Those are the main things that we see coming in, is that these things weren’t implemented. So when you make a change, you have to make it in ten different places. Or you make one change and it breaks ten different things, and there’s no unit test to back it up. There’s no documentation on it. So that’s stuff that we all very much focus on here, is to make sure that at the end of it, the client has unit tests. They have documentation. They have QA. They know that these processes were followed, and they have outputs from it that will help them keep going in the future, that they can run these tests and our code still works. When they make a change, it’s there to help ensure that the change didn’t break anything else.
S1 15:06 Fantastic. So, they even inherit – after you’re done with the project – potentially, something like a road map so they can do regression testing in the future and not have to rethink and rewrite all of that?

S2 15:16 Yes.
S1 15:17 Fantastic. You also mentioned one of my favorite terms, which is OOAD – object-oriented analysis and design.
[chuckles]

S1 15:24 Java, of course, very much at its core, one of the earlier robust object-oriented languages. I’m thinking– since we’re highlighting and featuring Java here, that – to me – seems like a language and a framework that gives one like yourself opportunity to really think through that more of an object-oriented design mindset as well. Is that true here at the Nerdery?

S2 15:50 Yeah, definitely.

S1 15:53 Do get to actually participate in activities? I’m thinking, when you mentioned earlier, opportunities to create something from scratch. Do you actually get to architect more or less at the whiteboard wall or on paper that object model of how you’re going to structure your code, and then develop? Or is that not quite the way?

S2 16:10 That’s definitely the way I work. I came from a more database background. When I architect, it’s definitely starting from the data model, and then building from that. So, I’m definitely in that camp. I would assume that most Java devs are also taught to architect that way, but I can’t say for everybody else. But we’re definitely architecting a lot of applications here, or at least a portion of an application. So there’s a lot of opportunity for that kind of work, which I really enjoy.

S1 16:50 I can see why. It’s fascinating to be able to think through that. And it’s interesting that– some of these other languages that we touch here at the Nerdery so often are starting to, or are have already – for a number of years, now – inherited a lot of those same principles too. I’m thinking even some of our PHP people, who are now thinking more like what I would imagine a Java dev would be thinking in terms of object-oriented.

S2 17:13 And then, we have the other way around too, where Java is getting more functional with languages like Scala. So, we’re coming both ways [chuckles]. Other languages are getting more OO, and we’re getting a little bit more functional.

S1 17:28 Obviously, OO – object oriented. We’re trying to model– represent essentially things that I can interface with in the real world, more or less. I can capture that thing. I can encapsulate some information about its state and its behavior, and bundle it all up into an object. I can inherit from that – children – and have that percolate through my design, and really leverage it in that way. That, I get. Functional, I don’t. So please–
[chuckles]

S1 17:56 –help me get with it on functional programming.

S2 18:01 Functional is more the other side of the coin, where you just– you don’t really encapsulate an object so much as do things in order, ‘We’re going to run this, and we’re going to run this, and then we’re going to run this.’

S1 18:18 So much more procedural, and almost like scripted languages in that way?

S2 18:19 Yes.

S1 18:21 But that can’t be the sole benefit of it though. It seems like functional programming is more– I don’t know, tricky than that.

S2 18:28 I haven’t thought of how to explain it in a non-techie way yet.
[laughter]

S2 18:40 But definitely, trying to bridge the gap between the two, where it’s less strict on the whole object design, and trying to reduce the redundancy in the code. If you’ve done any Java, you know that there’s a lot of boilerplate code. Scala is trying to get rid of that to save time for the developer. So when it compiles, it’s actually compiling to Java. But it’s taking out all that stuff that you don’t really need to worry about as a Java dev, and just focusing on what you actually need to put in the code to make it do what you want. So it’s following that “don’t repeat yourself” principle, where– let’s take out the public-class statement, because that’s going to be in most Java files anyway. And just– not necessarily using that as an example of Scala, but an example of code that’s going to be reused throughout a class that the class should know about already.

S1 19:56 Got you. It seems like when I’m thinking functional now in Java, I’m thinking more back to that behavior again. I’m worrying less about some of the hang-ups and some of the conventions of the language itself, and I’m getting back to, What do I actually need this to do? What does it need to know about itself? Or what does it need to know about some other player in the system somewhere? And that’s it. That’s where my thinking goes. Scala helps me build up a skeleton–

S2 20:24 Right.

S1 20:24 –behind the scenes, as I go. Fascinating. Well, that brings us pretty much to the close of our time. Sarah, this has been really, really lovely. I really appreciate talking to you. It’s been a lot of fun, and happily for me – and hopefully for our audience – really informative as well. So with that, I thank you for your time, and it’s a pleasure getting to work with you here at the Nerdery too.

S2 20:43 You too.

S1 20:44 All right. With that, I’ll bid everyone a good day.

Play
Filed under NerdCast

NerdCast #86: Making the Case for UX and QA Partnerships

2014.02-Christopher-Stephan-Alex-HoferIn this episode of the NerdCast we discuss the crazy notion to bring Quality Assurance engineers into the usability testing process.  It’s not that much of a crazy notion the more Christopher Stephan and QA Engineer Alex Hofer talk throughout this discussion about bridging the gap between these two project activities concerned with quality control.

Host: Ryan Carlson

Guests: Christopher Stephan (UX) and Alex Hofer (QA)

Listen Now: Running Time: 0:22:11 / Subscribe on iTunes

Play
Filed under NerdCast

NerdCast #85: Targeted Cyber Crime – Discussing BlackPOS

NerdCast Album ArtOn this episode of the NerdCast we interview security experts Chris Wade and Jason Herbst from the Nerdery QA team. We look at the malware that was used to target high profile retail companies in a massive case of stolen data. The software called BlackPOS is a brilliant piece of software and in another context is genius in its design. Hear more about how the malware works, what it can reportedly do based on security research firms, and what Jason and Chris think of our current state of security.

Host: Ryan Carlson (Tech Evangelist)

Guests: Chris Wade and Jason Herbst (QA Department)

Listen Now: Running Time: 0:23:13 / Subscribe on iTunes

Play