I’ve been practicing semi-continuous deployments on Chirk HR since I’ve started (where I am deploying to production as soon as code is useful). I’ve been having a problem with the asset pipeline though because the assets:precompile task is taking minutes to run. Slow deployments lead to me not deploying as often, which caused a bunch of pain and slower feedback.

Part of this is because Rails generates assets twice, once for the digest version (/assets/application-2d25da195f64bf181b34b5d15972cca6.js) and once for the non-digest version (/assets/application.js). A tip I heard from Jeremy Kemper was to only use the primary version which will skip the non-digest compilation.

After a bit of searching, I came across another idea. Ben Curtis posted a capistranio task that will use git to see if your assets have changed and skip regenerating them if they haven’t changed.

This is huge boost for Chirk’s continous deployment since the majority of my changes aren’t asset related at all.

Tip: If after adding this change and deploying if you see that assets are still getting compiled, check your Capfile to make sure you are loading config/deploy after deploy/assets. Otherwise your custom precompile task in config/deploy is getting overrided by cap’s default task in deploy/assets. From Stackoverflow

Share

See also http://baby.ilanadavis.com/

Share

Bootstrapping Design was written at the perfect time for me. One of the guiding principles I’m building into Chirk HR is that software should be easy to understand. I’ve seen firsthand the difficulties and problems caused by confusing software. A big component to making software easy to understand is clear design. Not just “looks pretty” design, but how the software’s interface is laid out (visual design) and how people use it (user experience, workflow).

My troubles with design

Before Jarrod’s book came out I’ve spent about $200 on various design books to try and teach myself the minimum of design to make something feel right. I never found the right resource though:

• some were too technical (e.g. Photoshop tutorials)
• some were very print biased
• some went way too deep too early
• and some had great theory, but nothing actionable

Suffice it to say, the design books “looked” right but I nothing in them really stuck and I was having a hard time making things look right.

So I stuck with hacking on premium templates and figured I’d pay a few grand later on for a custom design for each product.

Bootstrapping Chirk’s design

When I started development on Chirk, Jarrod’s preview chapter convinced me that I should try to build my own design. Having already build a few product sites based on templates, I knew I’d have to use at least a half dozen hours to get a template into a workable state. Starting a design from scratch would take more time but Jarrod gave me the idea of bootstrapping the design in order to launch:

…the minimum design fundamentals that bootstrappers must understand in order to launch a business…

Early on in Chirk’s MVP I decided to use Twitter bootstrap for its grid and form styling. Then I layered on several concepts from the pre-beta version of Bootstrapping Design and things really started to take shape.

Application design - Twitter bootstrap + custom design

I’m not going to win any design awards for my design, but that’s not the point. The point is that I created a good enough design myself, without much time or money, and was able to launch my product. Most important of all, I also understand the design choices I made and can iterate the design along with the application itself.

Launching page design - WordPress + custom design

Here is a short sample of the ideas I got from the book:

• anyone can be a designer, it’s just a skill
• don’t worry about being creative, “focus on simplicity, clarity, and the cold, hard science of what works” [for me, this is a HUGE killer of my analysis paralysis]
• basics of layouts, grids, and alignment
• using space to draw the eye instead of only color
• simple way to do typography, which has had the biggest impact on my design
• a hack to have a “good enough” color scheme without pulling out the color wheels
• bootstrapping a logo design

(Full disclosure: I was given a free copy of the early version but I still bought the latest version. It’s that good).

Share

Chirk HR is a web application for human resource professionals to find and hire better applicants. Using the pool of applicants that every job posting generates, Chirk HR will let HR reuse the 99% of applicants who weren’t offered a position the first time. In other words, a job posting might have 100 applicants but since only one person is hired in the end there are 99 applicants who aren’t hired. Chirk HR helps reuse those 99 applicants with the next position.

Chirk HR is still new. It is the creative atom from 30×500 or the MVP from Lean Startup. Raw, simple, and (hopefully) useful.

If you want to get early access, you can register to be notified below or read more about Chirk HR on the website.

Share

Example:

desc "Download missing plugins from Github"
task :plugins do
  # ..
end
 
namespace :plugins do
  desc "Fetch latest revisions"
  task :fetch do
    # ..
  end
 
  desc "Push latest revisions"
  task :push do
    # ..
  end
 
  desc "Cleanup repos"
  task :gc do
    # ..
  end
end

In this example I use Rake’s namespaces to organize and group similar tasks. This shows up when I run rake on the command line like:

rake plugins        # Download missing plugins from Github
rake plugins:fetch  # Fetch latest revisions
rake plugins:gc     # Cleanup repos
rake plugins:push   # Push latest revisions

By organizing rake into namespaces I don’t have to come up with a_unique_and_really_long_task_name for every task.

Another nice feature of Rake namespaces is that you can reopen them and add to them, either in the same file or a different file. The following example is the same as the first.

desc "Download missing plugins from Github"
task :plugins do
  # ..
end
 
namespace :plugins do
  desc "Fetch latest revisions"
  task :fetch do
    # ..
  end
end
 
namespace :plugins do
  desc "Push latest revisions"
  task :push do
    # ..
  end
end
 
namespace :plugins do
  desc "Cleanup repos"
  task :gc do
    # ..
  end
end

While I recommend the first example instead of the second one when your tasks are all in a single file, reopening becomes useful when you are trying to use a common namespace that was defined somewhere else (e.g. inside Rails).

With plugins it is also good to prefix your plugin’s tasks in a namespace so they don’t conflict with other tasks.

If you need more rake namespace examples, post a comment below. I have a bunch of them I’ve written and I’d be happy to share.

Share

The 3.0 series is my favorite release so far. It finally brings in some features that I’ve been wanting to use for at least 4 years. The full release details is on the official ChiliProject blog but I wanted to outline a few of the key features that I’m going to be using (and how I’m going to use them).

New Design

The most visible change in 3.0 is the new design. This is a cumulation of the work I did with Shane Pearlman and Peter Chester of Modern Tribe (formally Shane and Peter Inc). Originally this design was a theme plugin that was used by half a dozen companies.

Late 2011 the design was moved from the plugin into the core code to become the default theme. After that the developers at Finn Labs created another major redesign and let the ChiliProject developers iterate on it to create the final design that you see now.

The design is still a work in progress (as all designs should be) but there is already a huge improvement over the previous one.

Liquid

Liquid is another major feature that made it into ChiliProject 3.0. It started as custom development for a client of mine, which was then updated and merged into the core by Holger Just.

Liquid replaces the basic wiki macro system in ChiliProject with a powerful templating system (you could call Liquid a programming language). What this means is that every “wiki” text field will accept Liquid and will let the user write and run small programs, without having to touch the server or Ruby.

I posted an early example of Liquid in action on my personal tumblelog. (full size)

I’m excited for Liquid because I use wiki pages a lot for creating simple project dashboards for clients. It’s easier to use a wiki page and create the dashboard by hand then to write some custom code for each client. Now with Liquid, I can automate some of the data collection and make the pages even more dynamic.

Tagging

Tagging support was also added to ChiliProject. It’s not complete since it is only the underlying data structures (i.e. database tables). The good news is that by having the data structures in place, the rest of tagging can now be added in a minor release (like 3.1.0 or 3.2.0).

Personally, I’m looking forward to issue tagging. Like many people the issue categories are too rigid and tags would be easier to manage. I’m hoping I’ll get to add issue tagging myself, I have a prototype of them from a few months ago that I can port to the core code.

jQuery and jQuery UI

On the development side there are two huge features included in ChiliProject 3.0 that will make writing plugins easier.

First, ChiliProject is now including jQuery and jQuery UI in the core. Every one of my 70 or 80 plugins that have a user interface have been using jQuery. This means that each one has to include the actual jQuery library and use hooks to get jQuery included in the main layout. That’s a bunch of code that I’ve had to repeat over and over again.

With jQuery now being supplied by the core, I can remove all of that code and know that the plugin will always have jQuery available.

Having jQuery in the core also means that the core itself will start using it to provide a more interactive experience. A lightbox style popup has already been included and used to show issue description changes.

(Note: There is a method you can use to check if jQuery is included in ChiliProject. This is useful if you are trying to support multiple versions of ChiliProject or Redmine and want to load jQuery only if it’s not included. Use ChiliProject::Compatibility.using_jquery?.)

Capybara

The second feature that will really help plugin development is the inclusion of Capybara. Capybara is a fake browser that is used in the test suite and can simulate a actual person filling out forms and clicking links.

This is going to help make the tests more through and catch problems with activity flows (e.g. logging in and creating an issue, replying to a forum post). My hope is that with a powerful tool like capybara, more interactions will be tested in the core and in plugins, which will lead to better code and less bugs.

I’m really excited about ChiliProject 3.0.0. It lays down a great foundation that can be built on to improve the usability and user interaction.

Share

Images

Most themes will use images as part of the design. This is pretty easy to do because the entire theme is located in the public/ directory which is 100% accessible to the web server.

Using an existing image from Redmine would require you to go up a few directories but since all themes are in the same directory, it’s easy with relative paths. Lets say you wanted to use the package.png image which is located at public/images/package.png, you’d use this in your CSS:

... { background-image: url(../../../images/package.png); }

The three ../ are used to go up from the theme CSS file and into the main public/ directory (remember theme CSS is located in public/themes/theme_name/stylesheets/).

You can also add new images to your theme. Create a new directory called images/ for them in your theme’s main directory and use the url statement again, but this time you only need one ../ because you’re closer to the images.

... { background-image: url(../images/theme-image.png); }

JavaScript

Redmine themes can also include JavaScript, though you are limited in how much you can include. If you create a file in your theme called javascripts/theme.js then Redmine will automatically include that with your theme.

The limitation is that you can’t easily include other JavaScript files without a bit of work. Redmine only includes the theme.js file so you have to make sure all of your code is included there since JavaScript doesn’t have something like CSS’s @import.

You could inline third party code at the top of the file (like jQuery) using a JavaScript minimizer or you could use something like require.js to load additional libraries but this can get complex fast.

I recommend that you only include basic JavaScript in theme.js and create a theme plugin if you need something more.

Conclusion of Basic Redmine Themes

This wraps up all of the features for Redmine’s basic themes. I’m going to write about theme plugins next but before I do that:

Is there a question you have about creating basic themes? Post a comment below and I’ll be happy to answer it.

Share

Can I have a single issue display in two or more projects?

Answer: It depends. You can have them displayed if the projects are related (like a parent and child) but it isn’t very clear how to enable this.

Display subprojects issues on main projects by default

Even though an issue can only be in one project at a time, it can be displyed on another project’s issue list. This can only happen if the issue is on a subproject of the current project and you turn on the “Display subprojects issues on main projects by default” located in Administration > Settings > Issue Tracking.

What this option will do is it will mix issues from any child projects into the issues on the current one. It won’t show issues in the parent project though. For example:

• Project A
  • Project B
  • Project C
  • Project D
• Project E

If you are in Project B, then you’ll see issues on Project B and C only. If you are on project C, you’d only see issues on Project C.

Disadvantage: Always on or off

The major disadvantage of this option is that it is always activated system-wide. On larger projects or projects with a lot of sub-projects it can become difficult to find the issues you want because all of the sub-project issues get mixed in.

In ChiliProject

In ChiliProject 3.0.0 I changed how this option works. Basically the option was moved to the filtering options on the issue list, so you can include sub-project issues only when you need them. This means you have the option to include or exclude them whenever you run a query on the issues list (without affecting the systemwide option).

Do you have a question?

Do you have a question about Redmine or ChiliProject? Post it below and I might answer it in a later blog post.

Share

One of the areas of a lot of stress for me has been my obligation to my open source plugins for Redmine and ChiliProject. On one hand, I want to keep releasing new ones and new features because someone might find them useful. On the other hand, supporting and keeping them all updated has become a huge obligation for me (at last count I had 118 projects).

Inspiring by a presentation by Dr Nic, I’ve decided to do some major cleaning of my projects.

On my new Open Source page I’ve listed the majority of my projects and what state each one is. It has projects that I’m actively working on, ones that need a new maintainer, a dozen I’m abandoning, and more.

Hopefully this will clear up some of the confusion as to why some projects are active while others haven’t been touched in years.

Share

In my opinion a custom Redmine theme can really make your site stand out and also make Redmine much more usable than the default theme. But first, I want to explain what a custom Redmine theme actually is.

There are two types of themes for Redmine. The first is what I call “Basic themes” which I’ll be describing below. The second type are called “theme plugins” which I’ll be writing about later.

Basic themes

Basic themes are what is referred to in Redmine’s documentation most of the time. These are packages of CSS, JavaScript, and images that you can install and then enable in the administration panel. They are always system-wide and are meant to enhance or tweak the existing style of Redmine.

Basic themes are great if you want the same look in Redmine but perhaps with some new colors and styles. They are pretty limited though, especially if you want to re-organize how things appear on the page.

Minimum requirements for Redmine

To create a basic theme, you need to do a few things to have Redmine recognize the theme.

First you need to create a new directory in public/themes with the name of your theme, like public/themes/my_new_theme.

Second you need to add a CSS stylesheet to the theme called application.css. This file must go into the stylesheets directory and be named application.css. Example: public/themes/my_new_theme/stylesheets/application.css.

That is all you need to do but at this point you’ll won’t have much of a theme. In fact, you won’t have many styles at all.

Importing the main application.css

Redmine defines its default styles and the default theme in a file called public/stylesheets/application.css. This file has all of the layout and positioning information but it also includes visual styles like background and color schemes.

You will want to import this stylesheet into your theme, otherwise you’ll have to do all the layout and positioning in your theme. Use the CSS @import statement to do this. Basically this loads another CSS file into the current one (it’s similar to PHP’s include and Ruby’s require statements). Make sure to put the @import at the top of the file, before any of your custom styles.

/* File: public/themes/my_new_theme/stylesheets/application.css */
@import url(../../../stylesheets/application.css);

At this point, you can now start to customize and tweak the styles for your custom theme.

Note: As part of the redesign of ChiliProject for 3.0 I’ve been trying to change application.css to be more generic. That way it doesn’t contain as many style statements and is easier to override styles in a theme. As you might expect with a 2,500 line CSS file, this is an ongoing process.

Customizing styles

I’m not going to cover customizing the CSS that much here. At this point it’s basic CSS development, so any book or site on CSS can help you.

Summary

That’s pretty much the basics to creating a Redmine theme.

1. Create a directory in public/themes named after your theme
2. Create an public/themes/YOUR_THEME/stylesheets/application.css file
3. Add the @import statement to the application.css to pull in the main Redmine styles
4. Select the theme in the administration panel under settings

Another good way to learn how to create a theme is to look at some examples. The alternative theme is included with Redmine and shows some of the things you can do. My Open Source ChiliProject also has a custom theme that is built for the ChiliProject 3.0 layout. Feel free to see how it works, but ask for permission before you use any of it.

Now a question for you, are you using a different theme for Redmine? Is it an open source one or a custom one you’ve created? Feel free to post a link to it, I’m curious about how some themes look.

Share