There are a variety of reasons to work in a virtual machine. You might want to keep your development environment separate from a personal environment or you might want to use features in a different operating system. When using a virtual machine it may not be immediately obvious how to connect from a browser on the host machine to a server on the virtual machine. This article will explain the setup steps required.
Our arrangement that looks something like this:
Our host OS is Windows running Virtual Box. The guest operating system is Ubuntu running a django server. Before we begin we need to know the IP addresses of the host OS and the guest OS.
Windows Host IP Address
Open a command prompt and run the command “ipconfig”. This will list information about every network adapter on the system. Find an adapter that is assigned an IP address. Not this for later, we will call this the host IP address.
Ubuntu Guest IP Address
Open a command prompt and run the command “ifconfig”. This command will list all of the network settings for the linux guest operating system. Note the IP, we’ll call it the guest IP address.
Port Forwarding in Virtual Box
Virtual Box has the ability to route a port on the host OS to a port on the guest OS. To do this we will need to pick an unused port on the host system. We’ll use 8080. If this port is taken on your machine, pick a different port. On the guest operating system we can configure the Django server to run on any port. We’ll use 8000. We can run the command “python manage.py runserver <guest-ip>:8000”. With these settings in mind we can open the port forwarding settings in Virtual Box. We do this by right clicking the network icon and selecting “Network Settings…”
In the Window that pops up, click on the “Port Forwarding” button. In the dialog that appears, create a new rule. Enter the IP and port information collected earlier. After confirming your settings, Windows firewall may say that Virtual Box was blocked by the firewall. Create an exception to allow appropriate access.
Testing the Settings
Start the Django development server. Open a browser on the host OS. Change the address to <host-ip>:8080. The request will be routed by Virtual Box to the guest OS. If you see your Django project then the process worked!
Have you ever had software work on your machine and not work on a different machine? Missing dependencies is a common cause of software that works in one environment and not in another. Modern software is most often a tapestry of libraries and frameworks that must be present on a machine to function properly. Even the simple “Hello World” programs that are used so frequently to introduce programming languages require additional libraries to run outside of a development environment.
Windows Environments: Dependency Walker
Dependency Walker (depends.exe) is a tool that has been around for many generations of Microsoft windows. This tool is your basic tool for diagnosing Windows dependency problems in the field.
Unix Like Environments: ldd
ldd is a shell tool used to list dynamic dependencies (shared object files). This is your basic tool for diagnosing dependency problems in unix like environments.
Resolving Dependency Errors
Why is the dependency required?
Sometimes project templates for ISEs can incorporate common dependencies that you may not need for your specific application. Always determine why a dependency is needed. You should be able to account for every library and framework your application requires. This knowledge may also extend to the dependencies of your dependencies and so forth. While this process of tracing dependencies can be tedious, it can teach you a lot about the frameworks you use and the operating systems you distribute on. In simple terms, don’t carry any more dependencies than necessary. Each dependency is a potential vector for bugs and vulnerabilities.
Is your application built correctly?
Some operating systems (i.e. Windows) distinguish between debug and release libraries. There will often be restrictions on distributing debug libraries. Debug libraries are often associate with the developer’s machine only. The QT framework on windows is a perfect example of this. Applications linked for debug link to QT libraries with ‘d’ prefix (qt5cored, qt5guid, qt5networkd, etc.) This is case where something working on a developer machine and not on another machine is expected behavior.
Can static linking help your problem?
Some languages, such as C++, allow dependencies to be completely pulled into an executable at compile time. This means that the operating system does not need to resolve the dependency at run time because everything is already in the executable. The downside of static linking is that executable sizes increase and dependency updates require an entirely new application to be published. This had helped me in the past to incorporate Boost program options into an application. Static linking is not only language dependent, but also conditional on your licensing situation. Static linking to certain GPL works can cause the linking application to become a derivative of the GPL work and force the linking application to comply with the GPL terms. Consult appropriate legal and technical council for more information on this advanced topic.
Can you detect when the dependency is not met?
One common approach to dependency resolution is to check that prerequisites are met before allowing the application to be used. Visual Studio is a prime example of this approach. Visual Studio requires a number of companion technologies to be installed before the application can be installed. This does not prevent future problems because a user can uninstall still remove a prerequisite at a later time but it does set a nice baseline for what the publisher expected the system state to be.
Would setting minimum system requirements help?
Sometimes large sets of dependent files are distributed as a single update. An example of this would be service packs for Microsoft operating systems or names versions on Mac OSX (Yosemite, Snow Leopard, Mountain Lion, etc.) Requiring a specific update set can be an easy way to ensure dependencies are met. For example, when a minimum version of the .NET frame work is required.
Are you future proof?
Libraries change. Sometimes the way your software is written can cause unnecessary coupling between your application and the specific version of a library. My work supporting applications on Ubuntu has highlighted this idea. At some point in the life the software specific library versions get referenced. When transitions occur between 10.04 ->12.04, 12.04 -> 13.04 and 12.04->14.04 the default distribution for a library is based lined at a newer version. The older version are simply not present in the canonical package repositories. Sometimes members of the community post back borts for commonly used libraries but there is no guarantee this will be the case.
How Should the dependency be resolved?
Should you distribute the dynamic library or shared object file with your application? Should you rely on a different installer or updater to put the files there? How you answer these questions depends on the technology being used. Software is generally licensed, not sold. Software licensing dictates the terms that the software can be used and distributed. License restrictions may forbid the component from being installed by a third party. Others may all distribution as long as attribution is made. Some operating systems forbid or discourage the distribution of key system components. For example, it would be inappropriate to distribute a component that is normally updated through Windows Update. In some instances it may be appropriate to rely on a different installer to add and remove a component. The OpenSSL libraries are a good example of this. Every piece of software on the planet has bugs, including mission critical security software. Once you take ownership of distributing a library you are also on the hook for distributing all future security updates. If you don’t do this your software can either be disabled by system administrators or used as an attack vector against flawed software.
Do you ever wish you had a time machine? Maybe you would like to see ancient history first hand or re-live an important decision in your life? While we can’t travel through time and space, we can achieve a close second in our technical work using source control. Source control is kind of like a time machine for your plain text files.
A simple form of source control could work like the following:
- Do some work in an electronic document
- Save the file off with with a unique name at a given point
- Repeat steps 1 and 2 until the work is complete
This model works well for a small project with a single author. But this approach becomes problematic when different circumstances emerge such as
- Multiple authors are contributing work
- Two or more parallel works need to be merged into one work
- There are lots of files that need to be tracked
- Additional meta data is needed such as author, time and change notes
When one or more of these conditions emerge it becomes appropriate to utilize source control software. As is true with many universal problems in the software industry, the problem of tracking revisions has been solved with many different tools over time. As a frame of reference I have directly or indirectly dealt with seven different source control systems over the course of 14 years. A thorough comparison of source control systems can be found here: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software As with other articles in this series we will focus more on the factors to determine the right tool and less on any one solution.
Factors to Consider When Picking a Source Control Tool
What file types are being stored?
Most often source control systems focus on the task of versioning plain text (i.e. code and code like artifacts). They frequently do this using a difference concept where the changes from one version the next are captured. This also means that while some solutions are great at tracking plain text changes, they can also be terrible at tracking “binary” files such as images and office documents. If you are working with binary files, source control systems might not be a good choice
What is your environment?
One of the reasons why there are so many source control solutions is because there are so many ways to make software. Your environment might include one or more operating systems, official and unofficial IDEs of the team, and graphical vs. terminal workflows. For example, if you are using a Visual Studio based work flow in a Windows environment, Team Foundation Server may be a natural fit because it is seamlessly integrated with specific versions of Visual Studio. On the other hand if you have have a mix of Windows, Mac and Linux hackers you might want to consider a Git solution paired with visual clients like gitk.
What are your resources?
Some of the popular source control solutions have a price tag associated with them. Even “free” software can have a cost when paired with cloud services with a prime example being private repositories on GitHub. Different solutions may also require varying levels of infrastructure. Do you have a person who knows how to setup a server securely or setup a database? This infrastructure also needs maintenance over time to ensure availability, performance, and security.
What does the team prefer?
Developer productivity is an essential element in delivering a quality product. Productivity and morale will suffer a developer has to learn a complicated system or constantly fight a tool chain. Developers and other content creators should have a major say in the tools they are required to use. It is true that most developers like learning new things, but introducing too many new tools or technologies cripples a teams ability to craft new solutions. Keep the number of completely new tools and technology to one or two if you want to have any hope of making your schedule projections.
Common Workflows to Master
Regardless of which tool is selected as the right answer, team members will need to master a few common work scenarios. These skills are essential and should not be schlepped off to peers. Address avoidance of these tasks immediately because they could be:
- An indicator that more hands on training is required
- An indicator that the wrong source control solution was selected
- An indicator that corrective action and coaching is needed at an individual level
Universal Source Control Tasks
- Add a file or files to source control
- Remove a file or files from source control
- Obtain the newest version of a file or files
- Obtain a specific version of a file or files
- View revision history for a file or files
- Fork or branch from a given version
- Join or merge two versions
- Roll back to a specific version
- Create a new version and share it with others
- View the changes between two versions
- Mark or otherwise annotate specific versions
In this segment of Tools of the Trade, we will discuss the work horse of the software professional, the text editor. Every operating system comes with one or more options for for editing plain text. Plain text is different than rich text in the sense that the plain text files store just the text information on disk and do not store extra information such as formatting.
As with many other tools used by software professionals, text editors often invoke strong feelings akin to religious debates regarding which editor is best. This article does not seek to promote one solution over another, but it does seek to point out what a full featured text editor can do for you.
The first and most important rule when it comes to text editors is to heed the advice of the programming classic The Pragmatic Programmer:
Use a Single Editor Well
Features that you will grow to cherish:
- Syntax highlighting – Add variation to what you see on your screen
- Color schemes – Reduce eyestrain by switching to a color scheme that eases eye strain
- A Variety of Search and Replace Options – Spend some time reworking a legacy code base or absorbing a large code base
- Display Line Numbers – Code is already hard enough to describe to others, line numbers are invaluable when discussing technical details with others
- Show White Space and Non Printable Characters – You don’t recognize how wonderful this is until you have to debug a carriage return line feed issue.
- Support for Multiple Character Encodings – One thing you find out real quick when working with plain text is it is not always so plain and different operating systems and languages can throw a wrench in your plans.
With any tool, whether it be physical or software, it is important to try a few offerings and see what fits your work style and budget best. Keep in mind that plain text is perhaps as old as computing and there are a dizzying array of options for text editing.