All About Unidev

Here at Unidev we pride ourselves on the diverse skills and years of experience our development teams bring to their projects. Whether it’s custom software design or mobile application development, our developers have what it takes to provide innovative and elegant solutions to our clients.

But what exactly makes a great developer? Are there certain traits, skills or habits a successful developer needs? Well, we asked the talented members of the Java, .Net, and mobile development teams at Unidev to find out.

Testing

Of course, a great developer tests her code thoroughly to ensure it performs just as the client expects. Christine of the Unidev West development team in Las Vegas submitted the mantra, “testing, testing, testing” to highlight its importance. This element is essential in delivering high-quality code with confidence.

But testing isn’t simply a phase at the end of a project; it’s a mentality integral to the entire development process. We couldn’t say it any better than one of Unidev’s talented developers, Teresa:

“Besides having some test cases before he starts coding, [a great developer] is also thinking of test cases as he goes, so he can try to break his code in the testing phase. Oh yeah, and he tests his stuff- thoroughly.”

Communication

This development skill may not seem as obvious as technical skills or problem solving abilities, but it is extremely important nonetheless. Great code cannot simply exist in a vacuum, it needs to comply with client needs and function properly with code from other developers.

Strong communication skills reduce errors and can catch minor problems and miscommunications before they become major headaches. Kevin from our development team in St. Louis puts it best:

“A good developer must be a good communicator. He must be able to understand a client’s needs and then be able to respond with useful solutions. He must also be able to explain his development strategy to co-workers.”

Teamwork

Another intangible skill a great developer must possess is teamwork. Successful development may rely heavily on individual abilities, but without positive interactions between other team members, things can fall apart quickly. Brian, another member of our development team in St. Louis, shares his thoughts:

“Although development is largely an individual activity, ultimately the efforts of all the individuals on the team are combined to make the final program, product, or website. If a developer cannot handle the teamwork aspect, he/she will likely be limited to projects where his or her efforts will not adversely affect the larger team.”

These are just a few aspects that the Unidev team thought distinguished a “competent developer” from a “great developer”. Do you agree or disagree? Tell us what you think makes a great developer in the comments below!

 

The 2011 holidays are almost at an end, and here at Unidev we have celebrated them well! As you may recall, this year we held an office decorating competition. Web designers, software developers, web marketers, account managers, HR staff, and accounting all got involved in making the Unidev offices very festive. For a quick look at our holiday decorations, check out this video tour of our offices:

 

 

Clearly, the competition was stiff this year. From the inflatable figure and Bieber-adorned display of the web design team, to the wrapped paper shredder and toy train of the Auctori team, to the frosted glass and paper snow flakes of the HR and Accounting teams, the Unidev offices looked like a winter wonderland. But of course, there could only be one winner of the grand prize: The Best Office Decorations award for Holiday 2011. Who took home the blue ribbon? Watch our holiday party video below to find out:

 

 

So, as you can see in the above video, The Web Design and Development Team from our web marketing division The Net Impact are 2011′s winners for best office decorations! Congratulations to all the teams who participated. We look forward to next years competition!

Everyone have a happy, safe, and prosperous New Year. We’ll see you in 2012!

Live online video offers an unprecedented level of connectedness between users, events, and the brands that host them. Modern processors, webcams, and bandwidth speeds now allow companies large and small to become their own Live TV studio. Businesses can now stream company announcements, educational seminars, and valuable Q&A sessions directly to users on their website in real time.

Want to broadcast live video around the world but don’t know where to start? Here’s a quick guide to getting started with live streaming video, following the process used to get The Unidev Live Channel up and running.

Hardware and Equipment

Though the equipment is fairly simple, the hardware involved in the live streaming process is very important. The major elements needed are a camera, a microphone, and a PC robust enough to process the video.

A high-definition webcam is a simple way to capture video that is easy to encode and broadcast. For Unidev live we used a Logitech 1080p Webcam Pro C910 that cost around $70. This was a fairly inexpensive way to capture high quality video, and its USB output made it simple for encoding and streaming.

Next an audio capturing device is needed. While most webcams have a microphone, higher quality and flexibility is achieved with a dedicated microphone. For Unidev Live we used a MXL AC404 USB Conference Microphone for about $75. This microphone captured the ambient noise in the room, which was ideal for our discussion based events. Again, the USB output on this microphone makes sound capture and encoding very simple on a PC.

A fairly powerful computer is needed to process and encode the video and audio on the fly.  The CPU is the most important component. To achieve a desirable frame rate (at least 30 frames per second), the computer should be equipped with a dual or quad core processor. The computer should also have a decent amount of RAM (4 GB) and a dedicated video card with at least 512MB VRAM.

Streaming video also requires a certain amount of bandwidth to broadcast a quality video. Upload speeds should be around 1.2 Mbps to 1.5 Mbps. As always you can test your bandwidth speeds at speedtest.net.

Software and Service

Once all the hardware is in place, it’s time to select a streaming service to host your live channel. Justin.tv, Ustream.tv, and Livestream.com are all popular services that allow for free live video broadcasting. We decided to host on Livestream.com for The Unidev Live channel due to the simplicity of the interface and software, but all three services are capable and free.

It is possible to broadcast live video from the webcam on the Livestream.com website right away. However, if you would like to incorporate a feed from the desktop to include videos, slides, and graphics you will need to download capturing software.

Livestream.com offers Procaster, a small program that connects directly with your Livestream.com channel. Procaster captures, encodes, and streams the webcam video feed, the audio from the mic, and a feed of the computer monitor. This allows for live editing between video of the presenter and presentation slides on the computer, including picture-in-picture.

Live streaming allows businesses to create content in real time with their fans in a high impact medium. Additionally, the live player is fully embeddable on your website and the broadcasts are recorded and archived to show other viewers later.

This technology offers a great opportunity for brand building and consumer engagement. Overall, live video broadcasting does have some technical demands, but the content produced is very valuable.

Questions regarding live video broadcasting or video optimization? Contact us today!

Holiday shopping is just around the corner and we’re just weeks out from the biggest shopping day of the year, Black Friday. If you’re planning to purchase tech toys for the computer nerd in your life, you might think twice before purchasing the following items. Why? Because they might not even be around soon!

1. Standalone GPS Systems
2. E-Readers
3. Feature Phones (even if they’re only $19.99!!)
4. Low-End Digital Cameras
5. DVD Players
6. Recordable CDs and DVDs and here’s the kicker…
7. Video Game Consoles

We’d like to add USB cables to this list. All hail Wifi, Bluetooth and solar energy! But then again, they may still exist in 2020.

Seth Fiegerman lists these gadgets as the 7 Gadgets That Won’t Be Around In 2020 in a recent Yahoo! Shopping article. In the article, Seth talks about which tech gadgets will be phased out this decade. One surprising gadget that is often associated with “gift unwrap excitement” is the video game console. Ouch!

Video games will forever be popular, but will the separate consoles go away completely and all join as one on smartphone’s, televisions and computers? Seth’s article says, “The gaming systems that will succeed in the future will be those that manage to move away from being focused solely on video games and more on other entertainment options such as movies, evolving from a traditional game console into more of a set-top box.”

Think about the most recent release of gaming consoles, Play Station 3 and X-Box 360. Both of those allow you to access the internet, watch and rent movies and they even have Wi-Fi. But experts still say they won’t be in our homes forever. Rob Enderle, a principle analyst for the Enderle Group expects that consumers will instead buy smart televisions with a gaming system built into it.

If technology is only growing, imagine what the price of these new video games and accessories are going to cost. They already cost an arm and a leg.

What are they going to come up with next?

Interested in technology? Learn more about what Unidev can do for you.

Today, we take a brief moment away from technology and web design to commend Human Resources on a job well-done and to commend our developers and web marketers on their superb Chili-making skills. In case you missed it (and you probably did if you’re not a Unidev employee), here is a little background on this new tradition from Unidev’s very own Human Resources Manager, Maria.

Our motto for the event: “9 chili recipes…1 winner”.

Who knew that technology and the kitchen blended so nicely? We’ve listed overall winners and category winners below:

#1 Dhanya James – 2011 Grand Master Chili Champion and by a unanimous vote, winner of the “Best Afterburn” Award. If you’d like to know more about Dhanya, here is a fabulous blog post that she wrote on Hibernate Criteria sqlRestriction. Smarty pants.

Address Dhanya by her new title whenever possible. From this day forward, all new employees will be informed that Dhanya makes the best chili in the office.

Second place: A strong showing by Kayla Robinson (#5), that Texas Chili was great!
Third place: John Schoenecker (#7)
Most Original: Liz Maritz (#3)
Most Savory: Kevin Collins (#9)

Thanks to our other competitors for taking part and feeding the crowd, see what some taste testers had to say:

#2 Angela Trokey: “Nice and cheesy” “Awesome!”
#4 Laurie Woodruff: “Love the beans” “Good flavor”
#6 Maria Beaver: “Hooray for veggies!” “Good zucchini”
#8 Andrea Bemis: “Very original” “Nice variety of ingredients”

Great showing Unidev! We can’t wait until next year.

Unidev develops custom software and IT systems. The Net Impact is Unidev’s web marketing, web design and web development division.

With over 4 billion mobile phones in the world today, the need to develop a mobile application or a mobile website over just a standard website grows.

Web developers and web designers typically create standard websites with larger screens in mind. For example, a standard 19-inch, 5:4 aspect ratio computer monitor is going to be 1280 x 1024 pixels. A standard 19-inch monitor, 4:3 aspect ratio is going to be 1600 x 1200 pixels. It is common to find 22-inch monitors, 24-inch monitors and larger. As large scale computer and television monitors increase in size, it becomes even more important to develop mobile applications and mobile websites to display a “small-device-friendly” version of your website.

But after a company decides to develop for mobile devices, how do they determine whether a mobile application or a mobile website better fits their needs? So how do development costs, functionality, and hardware integration differ between mobile applications and mobile websites.

Below, some general truths about mobile applications versus mobile websites.

Mobile Applications (also known as native mobile apps)

• Mobile apps can integrate with the device operating system
• In many cases mobile apps still work offline (assuming that the application does not need to connect to the internet or a database)
• Mobile apps often better facilitate engagement due to their enhanced OS integration capabilities
• Users often download mobile apps to a mobile device and then store them on their dashboard for more frequent use

Mobile Websites (also known as browser-based sites)

• Mobile websites now look more like mobile applications (see m.target.com)
• User can load from URL, do not have to download and store the app to their phone
• Detect your device and display a special screen for that specific device
• Do not have to pay to develop a Mobile App for multiple smart phone operating systems, can reduce development cost by as much as 50-60%

Keep in mind that every business is different. A mobile effort must perform in terms of your goals (i.e. conversion rates).  Don’t just select a mobile application or a mobile website.   Ask some questions to make sure you’ll optimize return on investment (ROI)

1. Who is my customer?
2. How do does my customer use mobile devices?
3. What do we want customers to do as a result of this mobile effort?

At Unidev, we develop mobile apps and mobile websites.  Please contact us for more information.

We use some utility encryption routines in C for various purposes. When I first tried to migrate these routines from HP-UX to Red Hat Linux, I ran into a problem right away: the linker couldn’t find the libcl.a library.

There is no library by that name in Linux, and I had no idea what the linker wanted to find there. As an experiment, I edited the make file to remove the reference to –lcl. Now the linker complained that it couldn’t find the functions setkey() and encrypt().

A little research showed that, in Linux, those functions reside in the library libcrypt.a. I edited the make file again, replacing the reference to –lcl with a reference to –lcrypt.

(Under HP-UX, the libcl.a library includes not only the encryption functions but also a bunch of math functions. Under Linux, the math functions presumably reside in the library libmath.a. However I haven’t needed any of them so far, so I’m guessing.)

Now the linker was happy, but I wasn’t. Whenever I tried to encrypt anything, all I got was a string of zeros. Um, that’s not encryption. At best, it’s a really, really, really bad hash function.

At that point I fell down the rabbit hole of debugging – grepping the source, studying the code, inserting displays, Googling for clues, and trying experiments. Here’s what I found out.

The setkey() and encrypt() functions apply DES encryption to blocks of 64 bits at a time. That’s bits, not bytes. However, you don’t pass the bits as 8-character arrays. You pass them as 64-character arrays, one character for each bit. It’s the job of your application to translate back and forth between these bit arrays and whatever the data should really look like.

One reason for this arrangement is probably that not all machines use 8-bit bytes. The C language requires that a byte contain at least eight bits, but it can have more. I’ve heard of CPUs that use 9-bit bytes, and others that use 64-bit bytes. If you really want to be perverse, you could build a machine with 37-bit bytes. It may be easier for an encryption standard to support exotic architectures if it breaks everything down to the bit level.

In the HP-UX version of these functions, the bits in these arrays can be encoded as the ASCII characters ‘1’ and ‘0’. I haven’t found any documentation of that fact, but that’s how our programs were coded, and they seem to work okay.

In the Linux version of these functions, the bits in these bit arrays evidently must be encoded as the binary values 0×00 and 0×01. I haven’t found any documentation of that fact either. The man pages on both systems are ambiguous.

The best evidence is that, after I rewrote our code to pass the bit arrays with binary values instead of ASCII characters, the encryption started working on Linux. I can encrypt something and then decrypt it, and get the same thing I started with. Furthermore I can encrypt something on HP-UX, decrypt it on Linux, and get the right answer.

Out of curiosity, I tried the Linux version on HP-UX – and it worked! Evidently the HP-UX implementation of setkey() and encrypt() can accept either character values or binary values in their bit arrays, but the Linux version only accepts binary values. Once I converted the code to use binary values, I could use it on both platforms without a bunch of ugly #ifdefs cluttering up the code.

The C and C++ languages don’t try to define the results of every syntactically correct program.  For example, if you dynamically allocate some memory, and then free it, and then try to access the memory you freed, you invoke undefined behavior.  The C and C++ standards don’t specify how the program will respond.

Undefined behavior means that anything can happen, because the compiler is under no constraints.   The traditional formulation is that undefined behavior can make demons fly out your nose.  In practice the consequences are usually less dramatic.

If demons ever fly out your nose, you’ll know you have a bug.  You can track it down and fix it.  More insidious is undefined behavior that happens to be exactly what you want.

I ran across an example as I was preparing to port some code from HP-UX to Linux.  The program was freeing a linked list, using code similar to the following:

 

Node * curr_node = first_node;

while( curr_node )

{

free( curr_node );

curr_node = curr_node->next;

}

 

To a long-time C coder, this code immediately looks fishy, because the loop has only two statements in it.  Look a little closer.  The second statement in the loop tries to access memory through a pointer that has already been freed.  It invokes undefined behavior.

This program has been running for years with no obvious ill effects from this bug.  Apparently HP-UX isn’t very persnickety about accessing previously freed memory.  That’s legal.  “Anything can happen” includes “what you want.”

When I first saw this code, I wasn’t ready to port the entire program to Linux yet, but I could experiment.  I dashed off a little test program that built a linked list and then freed it, using the logic shown above.  Under HP-UX this program ran to completion without incident.  Under Linux, the same program stopped abruptly in the first iteration.  It didn’t issue any messages, dump core, or even leave a non-zero condition code; it just stopped cold.  That’s legal too.  Anything can happen.

I don’t know whether this difference is attributable to the operating systems, the compilers, the libraries, or the machine architectures.  I don’t care.  What matters is that I can’t run this program under Linux without fixing the loop:

 

Node * curr_node = first_node;

while( curr_node )

{

Node * temp = curr_node->next;

free( curr_node );

curr_node = temp;

}

 

A few days later, another example of undefined behavior popped up, in the form of a buffer overflow.  Under HP-UX the overflow had no visible effect, at least not until I started poking around with printf statements.  Under Linux the code just didn’t work.  Probably the variables are arranged differently in memory.  In HP-UX the overflow didn’t damage anything that mattered, and in Linux it did.

These examples are just things that I stumbled across.  There will be more, and I won’t catch them all so painlessly.  Fancy code analyzers may help catch things in advance, but there is no substitute for vigilance.

It’s tempting to conclude that HP-UX is more forgiving of blunders than Linux is, since some things work in HP-UX but don’t work in Linux.  That conclusion is premature.  Maybe the two platforms are just forgiving about different things.  If the bugs had done obvious damage under HP-UX they would have been fixed already.

There’s a Darwinian process at work here.  Bugs survive when they’re well adapted to the environment.  When the environment changes, some of those bugs will go extinct.  Unfortunately, new species will probably replace them.

You might think that migrating from HP-UX to Linux would be a piece of cake. Hey, they’re both UNIX, right? Sort of?

Naturally, it’s not that simple. Even among two UNIX-like environments, there are all sorts of pesky little differences to trip over. Typically the resulting problems are not hard to fix, but they can be hard to anticipate.

Lately we’ve been migrating an application from HP-UX to Red Hat Linux, and stumbling over a series of little gotchas. I plan to report some of them on this blog, and maybe save somebody else some hair-pulling.

For example: take the echo command.

Under HP-UX, echo recognizes escape sequences such as “\t” for horizonal tab, “\n” for newline, and so forth. Under Linux, it doesn’t, at least not by default. However the -e option tells the Linux version to recognize escape sequences.

One solution would be to look through all our shell scripts for ones that use echo with escape sequences, and fix them. Ideally, I should do that. However, the search would be tedious and time-consuming.

Instead, I defined the following alias in a logon script that everybody goes through:

alias echo=”echo -e”

If you really want echo not to recognize escape sequences, use the -E option, which works even with the alias in place. When the -e and -E options are both present, the last one wins.

Pedantic details:
Under HP-UX, the echo command is built into the shell, i.e. ksh and there is also a separate executable /usr/bin/echo. Both versions recognize escape sequences.

Likewise under Linux: the echo command is built into bash, and there is also a separate executable /bin/echo. Neither version recognizes escape sequences unless you include the -e option.

When a website’s database has been compromised with a SQL injection attack, it is important to clean it up as soon as possible. An attack of this nature passes SQL commands through a web site into a database. In the following case, many different HTML code statements were spread throughout multiple tables and columns. In short, the way to clean this type of attack is to identify the kind of injection, search for the offensive code, and then remove it.

Recently a company contacted us when they noticed a problem with their page titles. There was unknown HTML code, a script tag, showing up in the titles linking to ur.php, an obvious problem, so I began my investigation.

The first task was to find information about other sites which had also been attacked with the same HTML injection. A quick web search turned up the so-called LizaMoon attack which has been showing itself around the internet since at least autumn of 2010. LizaMoon has impacted well over 1 million different websites by inserting malicious code.

The next task was to determine a way to find all variances of the injected code. Besides looking for the URLs that had been known to be inserted (listed on many websites), I wanted to determine what other variants might be hidden in the good data of the database. To do this I compiled a list of strings that are not likely to be widespread in that database, including:

.js, php, script, .pl, .info, cfm, .inc

In order to search through all the tables and columns, I used the SQL script found here:
http://vyaskn.tripod.com/search_all_columns_in_all_tables.htm
I modified it to include text and ntext columns and then started searching.

Even though the SQL script was finding what I wanted, it still took time to look at some data by hand to determine exactly what to remove. I made a backup of the database before I updated anything, always a good idea before a mass update, and then started removing the injected code. Here are the strings I ended up removing:

<script src=”hXXp://asweds.cXm/ur.pXp”></script>
<a style=”display: none;” href=”hXXp://bookavio.cXm”>book</a>

(“http” replaced with “hXXP” and “.com” replaced with “.cXm” for purposes of this posting only.)

There were ten variations of bookXXXX.com that I found in the data (where XXXX was always a set of 4 other letters). As you can see, besides the script tag, all of the links contained the word “book” and the “display:none” CSS. So that knowledge helped me find additional variants.

Once I started seeing the injected code snippets, I needed to get rid of them. I found a great global search and replace that I also modified for my needs to use text and ntext columns.
http://vyaskn.tripod.com/sql_server_search_and_replace.htm

Here is a list of additional strings I searched for based on what I had found from the known injections:
asweds
lizamoon
ur.php
display:none
//book%.com

Since injection code viruses like LizaMoon, and others like it are not likely to disappear anytime soon, it is important to know how to walk through the steps of deleting such code from databases. There is no need to panic if you are faced with one of these SQL injections. With the right information it can be no more than an irritation.