TeamCity 9 uses WebSockets for UI updates. If you are using TeamCity 9 behind an Apache proxy, you will have to make some changes to the configuration for TeamCity 8.
Before creating build configurations, you should perform some basic configuration on your TeamCity server.
sudo apt-get install iptables-persistent
Create the firewall rules:
sudo nano /etc/iptables/rules.v4
Use these rules as a starting point:
On the old server
Create a backup
- Log into TeamCity with an account with administrative rights.
This tutorial shows how to install TeamCity on a Linux server. Please note that you will need a Build Agent that runs on Windows if you want to build .NET projects.
This tutorial shows how to use Apache as a proxy for Confluence, JIRA & Stash.
We will configure Apache so that it only accepts SSL connections, but without the need to enable SSL in the TomCat instances of Confluence, JIRA & Stash.
Each application will be available at its own sub domain, e.g.
On the old server
Create a database dump
These instructions detail how to prepare a new Ubuntu 14.04 LTS server for a Wordpress installation.
The following instructions detail how to install Java (JRE or JDK) on a Ubuntu server.
To setup SSH port forwarding for Atlassian Stash on Ubuntu, perform the following steps:
These are the steps to setup a new Confluence database or to move a Confluence database to a new server. The steps are the same for other Atlassian products. The only difference is the role name and the database name.
Setting up a virtual machine with Ubuntu Server is very simple.
- Download VMware Player
- Download Ubuntu Server ISO. I downloaded Ubuntu Server 13.04.
- Create a new virtual machine using VMware Player:
- Select “Create A New Virtual Machine”
- Choose “Installer disc image file” and select the downloaded ISO. It should detect the Ubuntu version and offer “Easy Install”.
- Enter your name and the details of the initial user account
- Provide a name and location for the virtual machine
- Start installation
As far as I know, Xamarin hasn’t yet released an installer for Visual Studio 2013 Preview 1.
Until they do, you can follow these simple instructions:
Trying to unit-test code that relies on global state can be a frustrating experience. Global state is shared among tests, making the tests no longer independent. This can lead to subtle bugs in the test suite, e.g. a scenario where tests seem to fail randomly when executed in bigger batches, but pass when executed alone. Tracking down - and eliminating - the state sharing can be both time consuming and frustrating.
MvvmCross makes heavy internal use of Service Location and Singletons.
This results in necessary setup before being able to use it in a unit-testing scenario.
It has been pointed out that the implementation of the Fluent Repository base class I showed in Part 2 has a big flaw:
You need a new instance of the repository for each query, because the base class is mutable and thus it appends the query conditions to the internally stored
IQueryable<T>. That’s not obvious and in fact counter-intuitive and because of that, it is bad.
A reader asked how to implement the Fluent Repository for Microsoft’s Entity Framework.
Here is how:
The last article showed a simple implementation of the Fluent Repository.
Now, if you have a lot of entities it makes sense to extract as much of the repeating code as possible into reusable code to make the actual query implementations to only contain the query logic.
Problem with classical implementations of the Repository pattern
After establishing that the Repository pattern is still the pattern of choice for separating the domain layer from the data access layer, I want to talk about a common problem when implementing it: Method explosion.
Introduction - what is the Repository pattern?
The Repository pattern has been around for quite a while. It was described as follows:
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
The Repository pattern is a powerful pattern to separate the domain layer from the concrete implementation of the data access layer (DAL).
Another quick one:
After I fixed the problems with the GitHub plugin, I discovered that the little arrow at the top of the page between the content and the sidebar - the one that allows you to remove the sidebar - no longer existed.
In my last post about the syntax highlighting of this blog I explained how to get Google’s code prettify to work.
Both options presented require me to add some kind of marker to the code blocks. That quickly started to annoy me. What I really wanted is the highlighting to happen without any markers, just like on Stack Overflow.
The last article in the series about the blog itself shows how I actually publish the generated content.
One goal for when actually writing my posts was low friction. I didn’t want to execute ten different commands to just commit the fix of a typo.
One thing I liked very much when I started exploring the world of static blog generators was the ability to have the raw data (the markdown) of all of my posts in a git repository. Nicely versioned and all.
But I didn’t want this repository to be public - no one really needs to see the intermediate states of my posts. Additionally, I didn’t want my posts to be in that huge Octopress repository.
After Octopress was up and running, I performed some tests. Being a developer, the first and most important test was about code.
As many others starting a blog with a static blog generator, I will dedicate the first posts to talking about my setup.
When I decided to finally start a blog, I had one main requirement the blogging engine had to fulfill:
I wanted to write my posts in Markdown. Being a rather active Stack Overflow contributor, I became fond of and fluent in it.