Note: Here's another great community post. This time, John Coggeshall covers how to get started with virtualization.
Regardless of the particular programming language you consider your flavor-of-the-month, if you do any amount of significant development one thing that’s consistently a pain is your environment. From large shops that need for developers to coordinate with DevOps for deployment changes, to the freelancer who has 10 different clients to keep track of – everyone needs to keep their development environments in check.
In this three part series we are going to show you how to create robust development environments quickly using a combination of open source tools (Vagrant, VirtualBox, and Puppet) that will make management (and getting from zero to writing code) quick and easy. To get started, let’s take a look at Vagrant.
What is Vagrant?
Vagrant is an open-source tool that manages the provisioning and creation of virtual development environments quickly, easily and most importantly in a completely reproducible way. Once you have Vagrant setup for your particular code repository (which is adding a single
Vagrantfile configuration file), you will be able to create and work with a consistent virtual environment at-will regardless of what operating system your actual machine runs on.
To get started creating your environment, first we need to download a few tools. Vagrant itself supports many different virtual environments (called providers in Vagrant terms) such as Amazon EC2, VMware, RackSpace Cloud, and VirtualBox. Because it is FOSS, we will be using VirtualBox as our provider so let’s get started by downloading and installing both to our local host machines:
Both VirtualBox and Vagrant support all common flavors of host operating systems, so simply pick which works best for you and get them installed.
Note: As I previously mentioned in this article we are
using VirtualBox for our provider – but Vagrant supports
many different providers to fit your particular needs.
Check out the available provider plug-ins Here
Once you have installed Vagrant and VirtualBox, we can get started configuring your project to use Vagrant environments! This is a super easy process, and one of the great things about it is that you can apply this to either a brand new project or an existing project pretty easily. To get started let's create an empty git repository to store all of our code by making a new directory on our host machine and running
git init in it:
Note: This is another great post from a PHP community member. This post talks about MySQL and InnoDB, written by the awesome Morgan Tocker, MySQL Community Manager at Oracle. Check out more about Morgan here.
Here is a question I've actually been asked a few times:
"I am writing a batch processing script which modifies data as part of an ongoing process that is scheduled by cron. I have the ability to group a number of modifications together into a transaction, but I'm not sure what the correct number is?"
First off, I think that this question is interesting not just in the context of batch processing, but it equally applies to all parts of the application. If you are designing a high throughput system for MySQL, there are actually some potential pain points that you can design your way around.
Potential Pain Points
Here are the situations where the size of the transaction could impact performance:
Welcome to our new site! We’re very excited to show you our new design and experience.
Before we embarked on the refresh of our brand and site, we carefully reviewed the design, architecture and content with customers, partners and employees. We set out to completely revamp the experience to meet the wants and needs we learned about during our studies.
Our objective in refreshing our brand was to stay true to our roots while also moving our company forward, communicating the power, reliability and security of our product and the support, expertise and innovation of our people. With our website, our objective was to simply and clearly convey what we offer, the value of it and our key differentiators. These principles guided all elements of the design, architecture and content of the site. We started with the logo.
Working with Fuzzco, we sought to create a flat, one-color mark that was strong, bold and a little fun. The font, called Avant Garde might be a familiar one to you. It felt timeless while also harkening back to the period when Paul Rand, who believed that a logo “cannot survive unless it is designed with the utmost simplicity and restraint”, designed materials for IBM. We did our best.
Paul Rand for IBM, 1981
Gradients were omitted from the logo in order to maintain its simplicity and lend itself more easily to printing and further exploration. We wanted to call out to our train-image history as well as our cloud focus, so we included a puff over the “I”.
While we moved away from a train in the logo, we made a new train to incorporate in our general identity. The letter ‘E’ shape coming from the mark was a pretty cool addition too, while that same puff from the “I” brings the mark to life in a simple way and ties the identity together.
The Lego-esque treatments of the train helped communicate what Engine Yard offers through our platform in terms of building blocks, flexibility and extensibility. Like a lego, our platform allows one to build, extend and add pieces.
As for our palette, we decided to keep red at the forefront but brighten and bolden it. We had our Pantone color books out for quite some time to try and find a color that wasn’t too tomato-y nor too bloody. We also learned that we have some pretty vivid color associations. Our palette now is more distinctive but still cohesive and restrained.
We also dug deep into our site and found what worked for visitors and what didn’t. We sought to improve by cutting down on jargon, avoiding overloading content and focusing on the journey of the visitor. We asked ourselves and others what they looked for in our website. Ultimately, it is vital to swiftly guide the visitor to what he or she needs from the site, whether it be technical information, support, product features or pricing. We conducted extensive user testing and took a long hard look at our site analytics and went from there. The flow of information should always be digestible and never clunky, especially in describing a product as faceted as Engine Yard’s.
We worked to develop a set of icons and illustrations that would compliment the concepts demonstrated without distracting. What resulted was an exploration of shapes with our new colors. Our brand instantly became clearer and more flexible.
But that’s not all! We’ll be rolling out more pages in the next couple of weeks, including our new and improved resources center and our brand new community section. We hope you like what you see and if you see any bugs, please do let us know. You’ll be handsomely rewarded with new swag!
We’ve been focusing on a lot of stack work (especially database stacks), provisioning improvements, and other projects that will reveal themselves shortly. Here’s what we released this week!
–Tasha Drew, Product Manager
Access Control by Environment
The access control feature we first released into early access in December has been very popular, and we are now making it the default on all accounts. It allows greater control over which environments collaborators have access to.
Access the settings by going to Account >> Account settings on the dashboard.
Then scroll down to the portion of the Accounts Setting page where you can invite people as collaborators to your account. You will now see collaborators organized by access level: Account owners, administrators, collaborators, and pending invitations. You can edit collaborators access levels from this page by clicking the edit button.
If you , you will see these new options:
invite someone to become a co-owner of the account, including access to view billing (you can only invite a new owner if you are yourself an owner)
give a new collaborator access to only some environments
give a new collaborator access to all environments and future environments automatically
If you choose to give a new collaborator access to only some environments, you can select which ones in the following workflow:
Our documentation has been updated, read all about it!
Social Calendar (Come say hi!)
Note: Here's another guest post from our friends at Black Duck, specifically Phil Marshall. Phil brings over 10 years’ experience in both product and services marketing as well as over a decade of experience in the high-tech publishing space with publications including Dr. Dobb’s Journal and Byte magazine. Prior to joining Black Duck, Phil was Director of Global Solutions Marketing at Ness Software Product Labs, a division of Ness Technologies. Before Ness Technologies, Phil held product marketing positions at both RSA and Sun Microsystems and was Director of Marketing at Compliance Engineering, a healthcare focused Systems Integration firm.
Lasse Andresen, CTO of ForgeRock recently wrote an article for SC Magazine in which he makes a great case for the relative security of open source software. That same month, Lucian Constantin, a writer for IDG News Service, published an article in PC World in which he describes vulnerabilities found and reported in seven popular open-source projects, indicating that there’s plenty of room for improvement when it comes to the security of open source projects. Can they both be right?
I’d argue that yes, they are both right. But to reconcile these assertions, we need to take a closer look at each perspective.
Lasse, to support his argument that open source software is more secure, lists four key observations regarding the use of open source. For enterprise users of open source, the takeaways are: