Part of the EllisLab Network

News

BAMify Ads

What can you tell us about the team that built the BAMify Ads site?

We are two senior developers from a successful development studio in the UK.  We spend our days making systems for large multi-nationals.  We also own dogs.
BAMify Ads Screenshot

What can you tell us about the site in general? What are the goals of the site and the main audience?

The first thing we want to point out is that it’s free.  Totally free.  No scams, no way of trying to pilfer money from people, no credit cards (ever).  The aim of the site is to offer free online advertising to anyone who wants it (meeting our ToS, eg. no porn, racism, etc).  The idea is to place what we call an ‘Adspace’ on your website which is just a couple of lines of JS, this then serves adverts to your site from our network.  Every impression of an Adspace earns you a bunch of credits (depending on the size of the Adspace).  You can then upload as many adverts as you like to our network, these ads are shown across thousands of sites and use the credits you’re earning on your own website.  We give you 5,000 credits for free upon sign up to get the ball rolling.

Interestingly, this can cause a sort of endless loop of credits.  For example, let’s say you have a couple of large Adspaces on your website homepage, and a few adverts running on the network.  If your advert has a good CTR then you will earn credits every time your advert is shown on the network.  For example, your website is bobsclothes.com, you have 2 Adspaces here.  I am a visitor to joesworkshop.com and I see your amazing advert, so I click on it.  That impression on joesworkshop.com has cost you a credit, but because I have clicked through to your website - bobsclothes.com - I have just earned you 10 credits because you have shown me ads for other sites there.

We have a few target audiences.  A lot of our users have small, independent websites; often blogs, hobby websites, that sort of thing.  There are also technical users, a lot of Open Source projects use us.  We don’t just deal with small sites though, we have a few large gaming sites that use us.

What was your major consideration in using CodeIgniter for this?

We like the small footprint CI has.  BAMify Ads serves tens of millions of ads, so we need something solid and scalable that doesn’t get in our way.  CI fits the bill.

What is next on the plate for the BAMify Ads site? Any additional functionality you can tell us about?

We have just introduced mobile ads.  You can now use BAMify Ads on your mobile-optimised website or a native App (Android and iOS).  There are libraries for some of the popular native App frameworks, such as Corona SDK (Ansca Mobile).  Placing ads on your app or mobile site is as easy as placing it on your website.

We’re in the process of revamping the stats and reporting areas of the control panel.  We want to be more transparent about where your credits are being spent and allow you, the user, to work out which adverts perform the best.

Do you have any other information you’d like to share with the community? Tips from this project you’d like to share? Lessons you’ve learned?

The whole project has been a learning experience for us.  Handling large data sets isn’t something you can just read about and understand, you need to see how much of an effect small optimisation changes can make.  Our success has largely been down to having a good product and being open with our users.  Our users like the product, so they not only use it, but try and get others to use it too.  That has helped our growth a lot.

Posted by Marcus Neto on May 09, 2012

Simplifying Tools Used for Feedback

EllisLab and the CodeIgniter Reactor team have been thrilled with participation in discussions, pull requests, code review, and idea submissions on GitHub.  It has resulted in a steady decline in traffic to the UserVoice forum that we opened prior to moving our codebase to GitHub, as the majority of those conversations have organically moved there as well.  So effective today, EllisLab and the CodeIgniter Reactor team are closing the UserVoice forum.

You can still comment on existing ideas if you wish, but voting and new ideas are closed, pending a deletion of the UserVoice forum which will take place on May 1st, 2012.  This should allow ample time for the community and team to move any discussions to GitHub from UserVoice that aren’t already taking place there.

Thanks to everyone who has contributed to these discussions!  We are confident that the simplification of how we gather feedback will make it easier for the team to monitor, and encourage the best exchanges from all voices.

Posted by Derek Jones on April 04, 2012

A Quick Look at Sparks

On the back of a CIConf in London last month, I would like to delve a little into a common theme amongst CodeIgniter developers. Speeding up development through simple automation. To do that we’re going to take a look at the CodeIgniter Sparks project and how it can drastically speed up your development. To demonstrate, I will walk through building a little portfolio that leeches off the GitHub API.

But first, what is sparks?

Sparks is a package management system for CodeIgniter. It hosts ready-to-go user contributed code that you can pull into your projects. If you have acquired a game through Steam; installed new software with Homebrew; or sped up your work with a Ruby Gem, then you already know what a package management system can do for you.

Why not PEAR?

PHP has an existing package management system, PEAR. Ideally a framework specific package manager would simply wrap around the language equivalent. Unfortunately with PEAR’s odd approach to packaging that isn’t feasible. It is regretable that the PHP standard has not enjoyed the success that gems, easy_install, and npm have seen.

How do I get it?

The getsparks website has installation instructions. For demo purposes I will use the option that isn’t listed on that page: The CodeIgniter reactor team has been hard at work getting sparks into the core, so I’ll be working from the sparks branch on GitHub.

Let’s get started!

Find a calm area somewhere in your webroot, and run:

git clone -b feature/sparks --depth 1 git://github.com/EllisLab/CodeIgniter.git 

This will do a shallow clone of the CodeIgniter Reactor repository and put us on the sparks branch. If you view the root of this new folder in your web browser, you should see the CodeIgniter welcome screen.

Next up, let’s find our first Spark. We can run sparks on the command line from the root of the CodeIgniter directory we just created. The command looks like this:

php index.php --spark <command[arguments] 

For example, to show a list of commands we can use:

php index.php --spark help 

You can also replace—spark with -s if you don’t want to type it out every time.

In order to build this little portfolio site, we need to access the Github API. We know that the GitHub API is a RESTful api, so let’s see if we can find something to help us using the search command:

php index.php --spark search rest 

You should see a list of packages. Scanning that list, restclient seems to fit the bill. Installing it is just as easy as finding it:

php index.php --spark install restclient 

A bunch of output should spring up. The important lines are at the end. We can see that sparks installed the curl library dependency for us. We are also told what version of the spark we just installed. Sparks have versioning built right in, so you can have multiple versions of the same spark installed in parallel.

Time to try it. Open up application/controllers/welcome.php and load your new spark at the top of the index method:

$this->load->spark('restclient/2.0.0'); 

Once it’s loaded, we will do a test request to GitHub.

$user 'github';

$this->rest->initialize(array('server' => 'https://api.github.com/'));
$repos $this->rest->get('users/'.$user.'/repos');

var_dump($repos); 

Sidenote: It returns false. This can happen on some local install, in particular MAMP, when there are certificate issues. If you’re seeing this, you can add the following in front of the get calls in this walkthrough:

$this->rest->option(CURLOPT_SSL_VERIFYPEERFALSE); 

So now we get data, but the output isn’t very pretty. So remove that var_dump and we will make use of a view instead. Rename the existing view to something more fitting (I like “home”). Then load it and pass along our repo data:

$this->load->view('home', array('repos' => $repos)); 

In that view we can now loop through our repos and output them in a pretty format. After taking a look at our previous dump, I decided to include the title, description, and a link to github.

<?php foreach ($repos as $repo):?>
<div class="project">
    <
h2><?php echo $repo->name?></h2>
    <
p><?php echo $repo->description?></p>
    <
a href="<?php echo $repo->html_url?>">View on Github</a>
</
div>
<?php endforeach;?> 

We are definitely getting somewhere. Now wouldn’t it be nice if we could also show off our awesome documentation right on our portfolio? Of course it would be. It’s usually a little more text, so we’ll start by adding a link to another page. Go ahead and add that to the loop in the view now:

<?php echo anchor('/welcome/docs/'.$repo->name'Documentation')?> 

We are using the url helper here, so flip back to your controller and make sure it gets loaded it as well:

$this->load->helper('url'); 

While you’re there, create the controller method for this action:

public function docs($which{} 

GitHub has a nice convention where any README in the project root is show as documentation. A lot of these are written in markdown, so for this example we will try to look for a “README.md”. GitHub’s API can once again give us most of what we need.

$trees $this->rest->get('repos/'.$this->user.'/'.$which.'/git/trees/HEAD'); 

I have picked up at the rest->get() call. The previous setup still needs to be run, but it is identical to what we had before. In my case I decided to add a constructor with any setup code.

We’re working with git and not a filesystem so the naming is a little strange, but a tree is basically a file. So we need to loop through all the files in the root and look for a README.md. Remember, you can always var_dump and double check your data. When I did this, I noticed that the API returns a new API url for the object data, so that is what I will store.

$doc_url = ‘’;

foreach ($trees->tree as $info)
{
if ($info->path == 'README.md')
{
$doc_url = str_replace('https://api.github.com/', '', $info->url);
break;
}
}

So now that we have the new api url for the readme, we can get the text for it as well. Note, that the content is encoded, so we have an added step:

$readme $this->rest->get($doc_url);
$content base64_decode($readme->content); 

We’re almost there! We can stick that output into a view and it will work just fine:

$this->load->view('docs', array('content' => $content));
// view:
<?php echo $content?> 

However, we really don’t want to show raw markdown to our visitors. Let’s go back to the command line and see what we can find:

php index.php --spark search markdown 

The markdown spark looks perfect! Go ahead and install it.

php index.php --spark install markdown 

Armed with our new tool, we can load up that spark, and render the parsed markdown:

$this->load->spark('markdown/1.2.0');
// in the view
<?php echo parse_markdown($content)?> 

And there you have it!

Of course, we do not want to run API calls for every request when we put this site live, or we will be in trouble very quickly. So as a last step, you should cache these pages:

$this->output->cache(60*24); // cache for a day 

Your finished controller should look similar to this: https://gist.github.com/2029827

And finally, thank you to the reactor and sparks team for the awesome work on this!

Posted by Pascal Kriete on March 13, 2012

Pancake App

Three days ago I received my copy of Inc magazine. I was scanning through it and low and behold there is a 1/4 page blurb about Pancake App! Phil is a leader within the CodeIgniter community and a member of the Reactor Team so I was very excited to see this. After doing some research I found that we have never done a showcase on Pancake App so this entry is to make that right. Congratulations to Phil, Lee, Bruno and Adam! You guys deserve the recognition that Inc. Magazine is bringing you.

Tell us a little about Phil and Lee.

Lee Tengum is a PHP developer with a keen eye for design. I am a long-time CodeIgniter user and contributor who also likes to build distributed applications. We make a good team, as I couldn’t design a website to save my life and I have plenty of experience building backend systems.

How did you two come to work together?

We’ve been working together on various projects for years now after we crossed paths on the CodeIgniter forums back in 2007. Lee built a very simple CMS which I ended up buying and that CMS became the great grandaddy of PyroCMS. Since then there have been a few client projects we’ve worked on and while Lee is a talented programmer we generally split the work as Lee on UI and myself on the main development. About a year ago Lee started building a simple internal application to collect payments from a difficult client.

After showing it to a few different people they were interested and wanted more features added in, which was when Lee decided to migrate the code to CodeIgniter and get more people involved. Throughout Pancakes lifetime it has had contributions from several prominent CodeIgniter developers and the team currently consists of Lee, Bruno De Barros, Adam Jackett and myself.

Pancake App website screenshot

What can you tell us about the app in general?

I like to describe PancakeApp as a freelancers sidekick. PancakeApp handles the full project life-cycle from Proposal to Payment. You can draft Proposals and send them to your client, who can then accept or reject until an iteration is agreed on, all from within the app. That saves a lot of PDF emailing! With the Proposal agreed upon you can make a Project, add Milestones and Tasks and even track time against each task. You can generate invoices based on the Projects which automatically take all your tasks and tracked time into consideration, so your Project is instantly turned into line items and totals. You can of course also create invoices from scratch. The invoices are sent to the client who then has multiple options of paying based on what you’ve enabled in the settings, so you can take money via PayPal, Authorize.net, Bank Transfer or even accept cash; instructions will be listed on the invoice.

You might be thinking of a hosted service that sounds similar too, but PancakeApp is not a hosted service. It’s a single payment to download the software and then it’s all yours to go on your own server. No worries about other companies having your client details, no monthly fees, just one payment.

There is one last thing that makes PancakeApp awesome: Auto-updating. If you turn this feature on in the control panel, PancakeApp will upgrade in the background as soon as we release a new version. You don’t need to keep logging into your FTP server to replace files or worry about running an upgrade script, we send out a HTTP notification to installations to grab the new files and CodeIgniter Migrations take care of the database changes.

I know you are on the Reactor team but when building something major like this you can build it using anything. So what was your major consideration in using CodeIgniter for this?

The most obvious answer would be that both me and Lee know the framework well and have been using it a long time, but the main reason is that CodeIgniter is currently the most simple and most portable framework around. While some frameworks undergo large rewrites to implement the very latest PHP 5.3 features, CodeIgniter maintains backwards compatibility for older servers meaning it is perfect for distributed applications in two ways: 1) We won’t have to re-write PancakeApp in a year, it has already gone from 1.7.x to 2.1.0 without a hitch, but also 2) it will work on PHP 5.1.6 servers. While as developers we have probably all upgraded any servers in our control to PHP 5.3 and are trying to convince our clients to upgrade theirs, when you release a distributed application like PancakeApp it has to work in as many places as possible and CodeIgniter makes that incredibly simple. After-all if we used a PHP 5.3-only framework and 30% of servers are still on PHP 5.2, we’ve just reduced our target market by 30%!

What is next on the plate for pancake app? Any additional functionality you can tell us about?

There are some brilliant features coming for PancakeApp at the moment. We’ve just finished up some improvements to User Management and Permissions meaning that you can add plenty of users with varying levels of access, and there are plans to improve the existing REST API even more to allow for more integration with other services.

Do you have any other information you’d like to share with the community? Tips from this project you’d like to share? Lessons you’ve learned?

The API is something I really wish I’d focused on more at the start. It is a well-known developer habbit to build an application or website then add the API in as more of an after-thought. While we are happy to have an API if we’d build it first and used it as a core for the system (much like Twitter does for example) then we’d have been able to make it much more powerful and have web features and API features keep up with each other without duplication of effort.

A positive lesson we learned was open, honest, personal customer support. While PancakeApp was still in its first year we had a few users on Twitter and in various forums make some complaints that certain features were not included. While some developers would take a defensive position, we admitted there was room for improvement and engaged them in conversation. Those users who complained all now have a PancakeApp license and have become some of our best evangelists. It’s thanks to users like this that PancakeApp has started to spread and we even got quite a big mention in Inc Magazine this month!*

Posted by Marcus Neto on January 25, 2012

ZoomShift

What can you tell us about the team that built ZoomShift?

Zoomshift is a rather young 4-person team composed of 2 developers, a designer, and a sales and content person. Our team is very tight knit and incredibly passionate about entrepreneurship and technology. We are strong believers in lean methodology and are constantly searching for new technologies to set our product apart. We all agree that we can’t see ourselves doing anything else. We love what we do and have a strong passion for entrepreneurship.

What can you tell us about the site in general? What are the goals of the site and the main audience?

The idea for ZoomShift was born from experience working in the service industry. From serving tables to selling tickets we realized first-hand that employee scheduling can be an absolute nightmare for many organizations. After doing some research we were unable to find a solution that was intuitive, affordable, and truly simplified the scheduling process. In turn, we decided to build ZoomShift with the goal of making scheduling simple for both employees and managers. Our vision for ZoomShift has always been very focused with the mentality that less is more. We focus on the core functionality of online employee scheduling and purposefully leave out all of the extra features that many other solutions provide.

Currently, we have customers ranging from restaurants and hotels to volunteer organizations and small medical clinics. ZoomShift is not designed to fit one specific industry, but rather it is intended to work for any organization that needs to schedule employees hourly. We love that our customers are other small businesses and from their feedback we are constantly finding new ways to make scheduling even simpler.

What was your major consideration in using CodeIgniter?

Choosing CodeIgniter was an easy decision for us. We wanted a lightweight and flexible framework that was relatively easy to learn. From a development perspective we didn’t want to be confined, and we knew that we would be needing to extend the framework quite a bit. CodeIgniter offered us a solid foundation in MVC that we could then comfortably build on top of. Also, it was incredibly important to us that the framework was well documented. The documentation was evidence to us that CodeIgniter was polished and built with care. We clearly made the right decision with CodeIgniter. It’s simple, not bloated, and suitable for the pro down to the novice.

What is next on the plate for ZoomShift? Any additional functionality.

Mobile is next. We have been waiting to pull the trigger on mobile development for a few months now. We really wanted to dial in the core feature set of the application before turning our focus to mobile. Now that we have a steady customer base and have validated our core features it is time to push onto mobile. While the current application runs smoothly on mobile browsers we want to offer our customers a native application for iOS and Android.

Do you have any other information you’d like to share with the community?

Build a strong team. It is the team behind a product that makes it great, and an idea is only worth something if you have the team to execute it. Finding a group of talented individuals that share a passion is incredibly powerful. Do what you love, talk about what you love, and go where other people are doing what you love. If you immerse yourself and reach out to others you will naturally build relationships with people that think like you do. These relationships will be a source of energy and inspiration as well as an incredible source of knowledge. Do what you love and make friends.

Posted by Marcus Neto on January 20, 2012

Page 1 of 14 pages  1 2 3 >  Last ›