Sunday, July 20, 2014

My first attempt at using AWS EC2

There are lots of cloud hosting services out there.   AWS is one of the most popular (if not the most popular), so I decided to set myself up with a free account so I could learn how to use it.   This blog post covers my initial experiences.
  • Signing up is very easy, just go to aws.amazon.com.   I signed in with my personal Amazon account, and created an AWS account.
  • I will probably be using EC2, and RDS -  An EC2 instance (VM) to host server-side web applications (Java) and RDS for the database.    I will probably use EBS as well, so I can have some durable filesystem storage for the EC2 instance.
  • I started with the "Basic" free tier.    You need to enter your CC information though, in case you go over the limitations of the free tier.   Since I'm mostly just going to be creating VMs for learning, mostly likely I won't be keeping too many instances running.

The free tier

Currently the AWS free usage tier gives you the following for one year:
  •  EC2 (virtual machines) - 750 hours/month on a 't2.micro' instance that is Amazon Linux, RHEL, or SLES
  • EBS (file system storage) - 30GB, 2 million I/O ops, 1G of snapshot storage
  • RDS (Relational db) - 750 hours/month on a 'micro' instance, 20G of storage, 20G of backup, 10M I/O ops
 See http://aws.amazon.com/free

What's a t2.micro instance?

T2 is Amazons instance type that is optimized for 'burstable performance'.   A t2.micro instance has:
  • 1 CPU and 1G of RAM.
  • Only EBS for durable storage (i.e. anything not on EBS will be lost when the machine is shut down).
750 hours per month?   Should I start and stop my instances?

You probably shouldn't start and stop instances too often.   The billing granularity is hourly, so if you start an instance, you might as well keep it running for an hour.    If you stop an instance, you might as well keep it stopped for at least an hour.

Also, if you start and stop an instance three times in an hour, Amazon will bill you for three hours.   So, you need to think about whether you really need to shut down or not.   This makes sense because Amazon probably doesn't want everybody to be constantly starting and stopping machines all the time.

See this page for more.

It is also a good idea to enable billing alerts.

Launching an Instance

Go to the AWS console, click on EC2.   Click 'Launch Instance'.
  1. Chose a machine image - Make sure you check the 'Free tier only' box if you want to stay in the free tier.   I chose Amazon Linux.
  2. Choose an instance type - t2.micro is the only free tier instance type, so I chose that.
  3. Configure instance - leave the defaults
  4. Add storage - leave the defaults
  5. Tag instance - leave the defaults
  6. Configure Security Group - Since I'm doing this for the first time, I created a new security group called "Administrators".   I chose 'My IP' for SSH access.   Should be good enough for today, and I suppose that I can change that access rule via the AWS console later to add new IP addresses.  Click 'Review and launch'

    Boot from General Purpose (SSD) prompt: keep the default choice.  Click Next.
  7. Review - This should all look okay, so just go ahead and launch it.

    Create a new key pair: Select 'Create a new key pair' and enter the key pair name.   You'll need to download the private key (.pem file) and store it somewhere.   I put my in a Google Drive folder so I could get to it later.

Connect to the new Linux instance with SSH


See this page for Windows/Putty and this page for Linux/OSX ssh.

You'll need the private key, the instance id, and the public DNS address of the instance.

Amazon Linux


This linux distro is in the Red Hat family - it uses yum and rpm.   Many packages are available to install.   I saw that mine had a Java 7 JRE installed, and that the yum repo had Tomcat 7 available, as well as MySQL and other things.

What's next?

  • Set up Tomcat, enable HTTPS access from the outside.
  • Set up MySQL on RDS - Connect Tomcat to MySQL.
  • Look into making my own machine images (AMIs) that have everything pre-installed and set up.
Once I get Tomcat->MySQL going, hopefully I can begin installing webapps to see how well the t2.micro instance works.    If it works well, I might consider moving my home wiki to AWS.

 I may also consider doing the same thing with Open Shift, to compare and contrast the costs and ease of use.







Friday, July 18, 2014

Eclipse for IDEA Users

If you are an IntelliJ IDEA user, there's a good chance you'll be working on a team with people who use Eclipse.   Here are some basics that will help you get the two environments working together smoothly.

Main Differences

  • The concept of a project is basically the same as it is in IDEA.
  • Eclipse has the concept of a 'workspace', which contains multiple projects.   You might make one workspace for your workplace, and another for an open source project or experiments.
  • Most of the features of IDEA exist in Eclipse, but they may be in unexpected places in the UI.  For example:
    • The plugins are installed / managed under the Help menu (and sort of under the About dialog?).  This will certainly generate a few WTFs.
    • 'Team' = version control.   That kept making me whinge.
    • Perspectives - this is kind of a 'mode' concept.   Mostly maps to the side/bottom panels in IDEA.

Install Eclipse

Best to just follow the directions.   Installation is usually not a big deal, but it's a good idea to:
  • Install the same version that everyone has on your team.
  • Install the package solution that is appropriate for the kind of development you do.   For me, this is 'Eclipse IDE for Java EE Developers'.
  • Here is an example of installing Eclipse on OSX.
    Basically: Download, unpack, drag the 'eclipse' folder into Applications (not the Eclipse application, but the whole folder).

Eclipse Plugins

  • Install plugins with Eclipse Marketplace, which is (oddly enough) under the Help menu.
  • Uninstalling plugins is done in the About Eclipse menu item, which is in the Eclipse menu on OSX.   See this wiki page for more.
  • You'll probably need to install a version control plugin (e.g. 'subclipse' if you're using subversion) and you'll need to install a dependency management plugin as well (e.g. gradle).
  • Often, plugins won't work until you delete the project from the workspace and re-import it into the workspace.

Getting Around

The Workspace


The workspace is a collections of references to project directories.   These show up as top level items once you have some in your workspace.  Eclipse will prompt you for a workspace when you start it up:

If you select 'Use this as the default', then you can easily switch workspaces using File -> Switch Workspace.

The Project Explorer will show all the projects added to the workspace.    At first there will be none, so you will typically import a project that is already on your disk.

Importing a project

This is how you get a project into the workspace, and it can be found under File -> Import, or by right clicking in the Project Explorer.  If you already have a git clone / svn checkout, the workspace will basically link to the existing location.   If you clone / checkout from version control, the default behavior is to put the files in the workspace directory.

To import a typical VCS clone/checkout that already has Eclipse project files in it, chose Generic/existing project:

The project should import successfully if you have all of the right plugins installed.   At this point you will probably want some additional views of the project: version control, etc.   This is where 'perspectives' come in.

Perspectives

Perspectives are basically different modes you can work with.   IDEA has similar windows, but it doesn't force the whole UI in to a 'mode' like Eclipse does.   To access perspectives, click the perspectives button:
The most important perspectives (from my perspective, at least ;-> ):
  • Team Synchronizing - This is similar to the VCS window in IDEA.
  • Java EE - This is basically the main project view in IDEA.

Project Files

Eclipse stores it's project information in two files .classpath, and .project, and a .settings directory.   These are roughly equivalent to the .idea directory and the IML files.

These can all be added to version control so the project can just be cloned/checked out and opened by other team members.

Things that you'll miss

So here are the things that you'll probably miss coming from IDEA:

  • Deep navigation and code 'grokking' - Eclipse just doesn't know as much about your project as IDEA does, so it can't help with some more advanced referencing and navigation.
  • Refactoring - Yeah, Eclipse has refactoring but it's very basic in terms of features and in terms of how thorough it is.   IDEA knows much more about the project, so it can refactor very completely.   With Eclipse, be prepared to complete many of the refactorings by hand.   It gets the basics done though: renaming local vars, extracting methods, etc.
  • Multiple classpaths - IDEA has separate class paths for testing vs runtime.   In Eclipse, there is only one classpath, so you may encounter some strange results when running tests or non-test programs from within Eclipse as compared to running them from IDEA.   My advice is to not rely on running your code from the IDE.   Always know how to do things from the command line as a fallback.
  • Change lists - If you're using Git, you won't notice this.   However, if you're (still) using Subversion, change lists don't seem to be there in Eclipse.    Maybe they are, but I haven't been able to find them yet.