As we discussed previously, we did a detailed comparison of multi-media video encoders from a variety of vendors. We chose 8 different criteria that we consider to be significant when evaluating streaming video encoders. This comparison does not consider the quality of the encoded video or other video editing/enhancement capabilities of the encoder. The opinion on these is subjective in nature and depends on the customers detailed requirements.
Encoder comparison table
by Ravi Ravishankar
Access to multi-media streaming features over the internet has grown rapidly in the last few years due to cost reduction and advances in this technology. Live streaming of video over the internet has become quite popular with most media outlets who make their broadcast available online. Additionally, many live events are being streamed directly from their location due to reduction of the cost barrier to entry. Fueling all this is the advances in the video encoder technology, both in terms of hardware and software.
To get a good sense of what these solutions offer and how they stack up against each other, I have compared some of the encoders from a variety of vendors based on certain criterion:
- A system that can stream a total of 4 input channels, 2 in HD and 2 in SD.
- The streamed video is viewable with Flash Media player. The two leading commercial media servers that support flash streaming are Adobe FMS and Wowza and the encoders should be able to stream to at least one of them.
The following are the capabilities that were compared:
o 1080p: This is the highest HD resolution available, but not all HD encoders currently support this.
o Storage: The ability to record and store video on the encoder platform.
o Latency: The video latency could be important in certain situations, such as in teleconferencing applications. It also may indicate the robustness of the encoding algorithm used.
o Multi-rate support: It is the ability to encode a single input video at different bit rates. A must if we need to support users with varying bandwidth connections.
o HD/SD Dual Support: Ability of a single encoder to accept and encode either SD or HD signal at a time.
o Public Management Interface: This is required when you build custom application to control and monitor the encoder. Typically all of them provide SNMP but some vendors also have implemented SOAP.
o Centralized Management Interface: Some vendors only provide single element management application but others have centralized management solutions. The centralized management solution comes in quite handy when you are trying to monitor and control multiple encoders.
o Cost Estimate: The approximate cost of the entire solution based on written and verbal quotes from the vendor. You should check with the vendor for the latest prices as they fluctuate often.
Come back next week for a detailed chart of the results.
As we discussed previously, there are four main considerations for developing a Windows Mobile application that are different from a Windows desktop application. Additionally, there are differences between Pocket PC and Smartphone devices that make it challenging to develop an application that works well on both. I explained how we overcame these challenges on the display and input fronts, and now I’ll finish up with details on the storage and battery life categories.
Use the “My Documents” folder for exchanging data files and documents:
When synchronizing files between a Windows Mobile device and a desktop computer, you can see the content of the “My Documents” folder on the desktop computer. The “My Documents” folder is very important on Windows Mobile. It is used for store data files and documents. If you have any documents stored outside the My Documents folder, they will not be synchronized with your desktop.
Battery life:
Windows Mobile devices are battery-based devices. Battery life will become much shorter if your applications are consistently sending or receiving data through Wi-Fi or GPRS or if they are running background tasks. The reason is applications with these kinds of behavior will not only use more battery power, but also prevent the device from going into the sleep mode. The latter is the key to saving battery power when a device is idle. When you design an application, try to avoid frequently exchanging data in the background. If you cannot, be prepared to use up your battery life much more quickly. This is not a good design practice as your users will become very annoyed if they find their batteries being draining more quickly.
MapleWorks is beginning to feel an easing of the effects of the recession through renewed interest in outsourcing.
Several prospects have begun to realize that they can no longer stand on the sidelines of product development and succeed in 2010. At the same time, they lack confidence that the economy has stabilized and still have concerns about cash availability.
Since they are at this crossroads, they have chosen to engage MapleWorks rather than hire full time staff to work on new product innovation. This way, they get the best of both worlds – MapleWorks’ expertise and experience, without the liability of full time staff. They can also reduce their need to use cash reserves for capital equipment.
Examples of these exciting new opportunities for MapleWorks include developing an element management system for a video server, developing a voice distribution system for a cloud voice over internet protocol (VoIP) supplier, porting an enterprise application to iPod and Android smartphones, and a peer-to-peer communication system for remote monitoring.
I recently worked on a project using Windows Mobile which supports two kinds of devices: Pocket PC and Smartphone. Our application needed to run on both types of devices.
My first impression of the Windows Mobile development is very good. Microsoft did a great job to make a universal development environment for both Windows Mobile and Windows desktop. Visual Studio can be used to develop both applications and it comes with a very good Device Emulator for Windows Mobile.
The Windows Mobile applications can be automatically loaded and run in the Device Emulator which speeds up debugging and testing. Microsoft keeps the same desktop Win32 API interface for Windows Mobile and technologies such as MFC (Microsoft Foundation Classes), ATL (Active Template Library) and COM (Component Object Model) can also be used in Windows Mobile. With previous development experience in Windows desktop platform, I didn’t experience much of a learning curve in the Windows Mobile development.
Despite the similarities, there are some differences that need to be taken into consideration when developing a mobile application. They are primarily in the areas of display, input, storage and battery life.
The application we most recently developed provided SIP services to the phone and I’ll explain how we took these factors into consideration while developing a top of the line application.
Some of the SIP services included a buddy list, online/offline presence, and call history.
Display Difference:
When your application needs to work on both a Pocket PC and a Smartphone, you need to pay attention to the differences in display screen size. A typical Smartphone screen is much smaller than the screen of Pocket PC. When developing the application to run on both devices, I had to consider the screen difference and design accordingly. This was especially true when adding the Buddy List pop-up menu. It is important to test both devices right from the start of the development cycle. For example, Smartphone has two hotkeys that correspond to two screen menus. If your application has more than two screen menus, these extra menus are not selectable on the Smartphone. It is easy to find this out by testing with both devices. If you don’t do this early on and mainly test the application on one device then when a problem is seen later, it could prove more costly and consume a lot more effort to fix it.
Input methods:
Pocket PC’s usually have a touch screen and it will let you enter data by clicking the keys on an on-screen keyboard or by using the stylus pen to write on a designated portion of the screen. Because of the limited size of the display, Smartphone does not have a touch screen, therefore it has no on-screen keyboard. Data entry on a Smartphone is more difficult than on a Pocket PC. For example, if you wanted to type the letter C on a Smartphone, you would have to press the 2 button three times. The Smartphone has no stylus pen. Using Smartphone is like using a PC without a mouse; everything has to be done through the keypad! Because of this, some user input tasks that could be easily performed in the Pocket PC may be very difficult or impossible on the Smartphone. When designing an application requiring user input, make sure to test it on both devices. If possible, try to avoid letting the user input long or complex words.
….more next week….
After wrapping up a VOIP project using a conventional waterfall process, I joined a group of very talented web designers on a web portal project using the Agile process. Both projects are quite large in terms of the size of the code base. Each release for the previous VOIP project lasted anywhere from 8 to 12 months. On this current project, a release normally takes around 2 to 3 months, which typically includes 3 to 4 development iterations, 1 regression testing iteration and 1 hardening iteration.
My first impression of the Agile process is that it is very progressive. I can easily see the progress made by each developer as well as the entire team on a daily basis. This was rarely the case in the previous waterfall development environment. The several initial releases of this project have confirmed my observation that being able to deliver early results, with much sooner return on investment if you will, is one of the Agile method’s greatest strengths.
The Agile process is light-weight as opposed to the traditional well-structured heavier waterfall process. Light-weight does not mean that there is less control or planning. My understanding is that the Agile process distributes the planning and control of uncertainties to each team member in many small steps over a relatively short period of time, avoiding the big long term visionary statements and aggressive targets often set during the waterfall process. Agile planning is focused more on individual estimates over a short period of time rather than a lengthy planning document covering a much longer period. The Agile process requires constant revisiting of plans and schedules. This benefits the developers and maintains clarity and focus. Individuals and interactions are the keys to build a common understanding of the project goals and the ways to reach them.
Changes of project requirements are often a nightmare to developers in the waterfall process because they have to rewrite their functional specification and design documents. They may have to re-architect their software implementation. All of these updates require re-review and re-approval. The Agile process, on the other hand, encourages and embraces the changing requirements. Product owners constantly give feedback to developers based on their discussion with customers. Developers are more adaptable to the changing UACs (user acceptance criteria). Because Agile uses iteration-based scheduling (versus release-based scheduling) and because a single iteration is much shorter than one release, any significant changes in UAC can be reflected in the new stories for the next iteration.
During the iteration planning and release planning phases, software developers, have to work very closely with product owners and other stakeholders. It is absolutely crucial for every one of the developers to be involved in this phase because in order for the developers to solve the issues, we must first fully understand them. This is much harder in reality than it sounds. The Agile process encourages individual accountability, self-organization as well as collaboration between stakeholders. In practice, we use daily stand-up meetings which include accomplishments and obstacles for that day and a list of the things to do the next day. In addition routine communications occur between team members including all stakeholders in the project. This prevents any hidden issues and encourages team members to respond. The Agile process emphasizes working software over cumbersome documentation. As soon as we check in source code and mark a development task as being completed, the QA team is able to test it without any delay. This guarantees that we deliver completely developed and fully tested features in a much shorter period of time.
No matter how well the Agile process is defined, a project’s success depends to a large extent on how well you follow the process. Understated documentation, such as user story or use case related documentation, could lead to confusion especially for a larger project. Team members tend to rely heavily on email exchanges and wiki pages to record design thoughts and discussions without any version controls. Team members’ flexibility in accepting the changing UACs is one of Agile’s strengths. However, changing UACs too frequently or too late in the iteration will cause a lot of frustration among developers.
As of now, my knowledge and experience with the Agile process is still very limited. Even without much formal training or many years of Agile experience, I am already excited with and quite encouraged by a lot of benefits the Agile process has offered to us.
Generally, the high tech market remains soft with no specific signs that things will improve in the near future. In the WSJ Venture Capital Dispatch on July 8, 2009, it was reported that venture capital funding plunged 63% ($5.1 billion) in the first half of 2009 as compared to the first half of 2008 ($13.6 billion). Across all asset classes, the amount of capital raised was down 64% in the first half of 2009 from the same period a year earlier. The inability to raise additional funding, has slowed the flow of funds into both new and existing companies.
There was one bright spot on the horizon as reported in the MHT on July 18, 2009. The second quarter of 2009 appeared to mark a turnaround for venture capital investing, as total dollars invested in venture-backed companies increased over the previous quarter for the first time since Q2, 2008, according to numbers released Saturday by Dow Jones VentureSource.
Nationwide, across all sectors, venture-backed companies took in $5.3 billion in Q2, 2009, spread across 595 funding deals, the financial tracking organization reported. The total dollars represented a 31.7 percent increase over Q1’s dismal $4 billion invested – the greatest Q2 over Q1 increase in the past five years. Nationally, numbers remained down compared to last year’s second quarter, according to VentureSource. Overall venture dollars invested dropped 36.7 percent, to $5.3 billion. IT investment dropped 41.4 percent, to $1.9 billion. Healthcare investment fell 14.3 percent, to $2.2 billion, and renewable energy investment dropped 75.4 percent, to $220.6 million, quarter over quarter.
(Paul Gasparro is Co-founder and Vice President of Business Development for MapleWorks – the smart choice for on-shore software development.)
The argument for BPO offshore outsourcing may hold water, but it does not apply when it comes to finding a partner to create innovative software products. The real costs of offshore can be found not in the unit labor costs, but in the cost of ownership associated with doing business offshore. There are the obvious ones such as the cost of travel, the cost of communication, and the cost processing H1B visas. The real costs are associated with having inexperienced people with a non- North American development culture attempting to meet the innovative demands of new software products that will meet market demand and enable a profitable business.
Start with the fact that only in North America do developers work in an iterative way with the marketing department to develop a product that meets the demands of the customer base. Going offshore means you are with an inexperienced work force that only knows how to build to specification. No room for deviation or creativity. Products just don’t get developed that way in the US, so the resulting build to spec product has to be built over and over again until finally it is market ready.
Compound this problem with the fact that the people building the product are unfamiliar with the technology and the problem becomes even more severe. Not to mention the fact that the people that started on the project probably are not the ones that are working on it when it is finished, since employee turnover can reach 40%-50% per year in many offshore locations. Oh by the way, did I mention that the language is different, and since the time zones are totally out of synch, there is limited real time communication to keep things on track. Then there is the management issue. Since you are dealing with an inexperienced development team thousands of miles and many time zones away, you need to dedicate staff to managing the team. Also, that manager must spend a lot of time in the foreign country, away from home and family, not doing much for employee morale back home. Hopefully, once the product does get built, your intellectual property will not get stolen and find its way to a position on the shelf next to yours at a fraction of the price.
Unit labor costs of doing business offshore is certainly lest than doing development onshore. But you get what you pay for, which are a big migraine and not much more.
(Paul Gasparro is Co-founder and Vice President of Business Development for MapleWorks – the smart choice for on-shore software development. He posted the above blog as a response at http://www.trybpo.com/offshore-vs-onshore-outsourcing-pros-and-cons/)
(Please welcome Krys Pritchard as our guest blogger this month.)
Where are the technical writing jobs? They aren’t in Ottawa. From what others in the field are telling me, the tech writing jobs aren’t in Seattle or Dallas-Fort Worth or the Silicon Valley or points in between. From the beginning of April through the end of June, there were four positions for technical writers advertised on workopolis.com in Ottawa. I know five senior technical writers who are looking for work. Not one of them landed one of those jobs. Only one of the five has a casual job, she is pouring concrete lawn ornaments. From words to concrete, that’s quite a career change.
The reality of being self-employed
Many technical writers, like others in the writing field, are self-employed. Self-employed people who are without work do not draw employment insurance benefits and are not counted in unemployment statistics. These non-working self-employed people also do not qualify for government-funded retraining programs. Non-working self-employed people are not dining out, having their clothes dry cleaned, picking up a loaf of bread at the bakery, going on vacations, or buying new cars, electronics, or houses. More jobs are affected by offshoring than those directly made redundant.
Business owners don’t blame the self-employed for a dip in your monthly or annual revenues; cast the blame where it belongs: managers at those companies that wanted to please their stockholders by reducing costs, regardless of the price to North American workers and the North American economy. When management started to view employees as “bodies warming chairs,” often the first body to be given a pink slip (or in some cases, sent an email that the person’s services were no longer needed), was the one that the manager perceived as contributing the least value to the project—often the technical writer.
These managers “discovered and exploited” the labor markets in low-cost nations to cut labor costs. The managers of a Canadian flagship company were so good at reducing costs through offshore outsourcing, the company shall soon be no more; stockholders will not receive any financial rewards from misguided decision to take jobs to China or India; and the labor pool of skilled and talented people available in Ottawa will grow. But where are the jobs for these talented people? IBM recently initiated a program called “Project Match” for its redundant North American workers to relocate to in India, China, and Brazil (http://www.informationweek.com/news/global-cio/outsourcing/showArticle.jhtml?articleID=213000389) has drawn heavy criticism in the business world. Employees who accepted this offer would work for the reduced wages in the lower-cost countries. Not to mention the difficulty to return to North America if they lost their newfound jobs.
© Copyright 2009 K. Prichard and Capital Writing Services. All Rights Reserved
Capital Writing Services is located in the Ottawa area. To contact CWS, E-mail cws@ripnet.com.
About the blogger: Krys Prichard, President, Capital Writing Services, has 20 years’ experience in the technical and business communications fields.
By Jeff Rappoport
Looking back at past test automation projects that MapleWorks has been involved with leads me to conclude that test automation is no different than any other software development project.
Typically test automation tools are built using scripting or programming languages; a commercial platform such as AutomatedQA’s TestComplete or Emprix’s Hammer; an open source platform such as STAF; or an in-house development platform. Regardless of the approach taken, test automation is a product. It is a stand alone tool used to trigger events and then report whether the event triggered was handled appropriately by the system under test.
The key attributes surrounding test automation are:
Understanding how the system under test operates is the most important component of any test automation activity. Knowing what triggers need to be injected into the system is crucial since the core component of any automated test case is to create activity on the system under test. Understanding what output is generated by the system under test is equally important because this output will be used by the test automation platform to declare whether the automated test case passes or fails.
Understanding the characteristics of an automation test tool is crucial in the construction of an action (the automated test case) from the desired intent (wanting to test the system). Each test tool is bound to some technology and each technology has limitations. The resourceful test case developer has the ability to use creativity and possibly out of the box approaches to bridge the gap between what is needed to trigger activity on the system under test and how to manipulate the test tool to generate this trigger. Understanding the automation test tool is also important in defining mechanisms for retrieving output data from the system under test.
A precondition essentially states what the starting point is prior to injecting the trigger onto the system under test. This precondition needs to be applied to the system under test as well as the automation test tool. A state machine analogy can be applied to this idea. In order to arrive at state “B”, event “B” must be applied from state “A”. Precondition requires that the system under test and the test tool be initialized and set to state “A”.
Creating an automated test case is the mechanics of applying the lessons learned from the previous two points in the construction of a tool to test the system under test. The test tool identifies the language used to create the test case and the decision making criteria in evaluating the test case outcome.
Verifying the outcome is a means to determine if the system under test is sane and behaving as expected. Once all the triggers are applied it is important to retrieve information from the system under test in order to evaluate its behavior. The automated test tool needs to obtain this data, and determine if the data meets expectations. If the expectations are satisfied then the test succeeded. If the expectations are not satisfied then the test case failed.
A failed test case is just is as valuable as a successful outcome because this suggests that the system under test is faulty.
Removing all evidence is an eye catching phrase to describe the post condition cleanup step. The goal is to place the system under test as well as the automation test tool into a known state so the next automated test case can be run. As stated previously, the test tool and system under test needs to be reset to state “A”.
At the end of the day successful test automation requires:
- Understand the product that needs to be tested
- Understand how the intended user is planning on using the tool
- Understand how the system under test reports a successful or failed outcome
- Prototype the most complex procedure the intended user wants tested
- Understand the technological limitations imposed by the system under test
- Understand the limitations imposed by third party tools
- Design a suitable architecture
- Implement the solution
