If you are scratching your head over where they stuck the php.ini file in MAMP 2 (both Pro and regular), wonder no more! Doing a quick spotlight search reveals the php.ini file is in one of two locations (based on the version of PHP you are running):
/Applications/MAMP/bin/php/php5.2.17/conf/php.ini
- or -
/Applications/MAMP/bin/php/php5.3.6/conf/php.ini
Hope this helps anyone who has been stuck looking for the file (as I was). Configure away!
If you are using Apple’s LLVM compiler and their Reachability.h file you may be getting warnings like this:
Reachability.h: warning: Semantic Issue: Declaration of ‘struct sockaddr_in’ will not be visible outside of this function
Luckily, there is a quick way to fix this. Simply add this import line to the includes section of the Reachability.h file:
Bam! Warnings gone. Hope this helps all you app developers using Apple’s latest preview releases that technically don’t exist because mentioning they exist would be against the Apple-Developer confidentiality agreement. ;)
There seems to be a lot of debate over the best way to replace the error_messages_for helper. It was removed in Ruby on Rails 3 because it conflicted with the core convention that Rails should not define the application’s appearance. To compensate the Rails team modified the scaffold tool to generate erb that iterated through the errors and displayed them. It looks something like this:
Well that’s cool, you might say. But isn’t another concept of Rails “Don’t Repeat Yourself” (DRY)? Isn’t having that code at the beginning of every form redundant? The answer to both those questions is of course “yes”, which is why I find it odd the Rails team chose to replace one problem with another. So let’s look at some of the alternatives:
Install the plugin that they exported the function to: While this solution is a great for those who want to upgrade their application quickly to Rails 3, it’s not exactly addressing the core issue or following the “convention over configuration” idealogy.
Create a helper function that outputs HTML to your template: Getting closer, but this conflicts with the idea that you should never directly output HTML because it defeats the purpose of the MVC system. The code also just doesn’t look very good (if that’s important to you).
Move the scaffold generated erb to a partial: Ding ding ding! We have a winner! One of the first videos I remember watching about Rails was the infamous “Create a Blog in 15 Minutes” tutorial. In that video one the first DRY concepts introduced is this idea of using partials. So why not do that here? It allows you to create cleaner looking code, follows Rails conventions like DRY, and is easy to use for all your forms! Easy, right? Let’s get started:
Partials are generally kept inside the same folder that houses the view they are used in. Since we are creating a partial that would probably be used across multiple views/controllers, we need to create a new folder inside our apps/views folder. I’ve named mine “shared” but you can use whatever name you like.
Inside your app/views/shared folder create a new file named “_form_errors.html.erb”. Remember, the underscore at the beginning is a Rails naming convention that indicates that this file is a partial.
As you can see, this code looks very similar to the code generated by the scaffolding tool, but with some important differences:
@model instance variable has been replaced with the local variable object. This variable will passed through from our form view.<h2> tags has been replaced with something more generic so that it may be used across all of our forms.Lastly, we need to add the render partial function to our form view.
And that’s it! Simply use the above code in any view you wish to display the form errors partial. I hope this has helped someone. If you have any questions/suggestions/thoughts on this be sure to let me know in the comments!
I am happy to announce that Prop Hunt has (finally) shipped with the latest update of Garry’s Mod! What are you waiting for? Fire up Steam, let Garry’s Mod update, and give it a try!
At work we have our own in-app ad system we use to cross-promote our apps. It’s been up and running for a couple months now logging impression and click-through data into a MySQL database. One of the tasks I was assigned with was creating the analytics page that turns thousands of rows of ad data into a user-friendly chart and table.
My first hacked-together iteration of this involved running a COUNT query for each day from the first logged entry to the last. The entire result was displayed in a chart and table using Google’s Visualization API. You could narrow your search by manually typing in a start and end date into a search or by moving the zoom sliders on the annotated timeline (this wouldn’t run a new query, just narrow the existing result). I knew this was an extremely un-optomized way of going about this, but I just wanted to get my feet wet with the Visualization API and we also wanted to see how our ads had been faring in the past few months.
The second time around I knew I had to limit the amount of data a user could look at. There was just no way the server could handle running a count query for each day. I also recently added logging of ad impressions to our ad API which meant that now 2 COUNT queries (1 for impressions, 1 for click-throughs) would have to be run for each day. After discussing with someone in our marketing department we decided that monthly reports would be sufficient. This limited the number of COUNT queries that needed to be run to a maximum of 60 at any given time. The results were better, but still bad:
I threw around some ideas on how to improve the speed. I knew that the most optimized way of fixing this problem was to create a new table that just contained rows with the count of impressions and click-throughs for each day for each ad. Every time the server received a notification of an ad impression or click-though it would just up the count for that day. There were several problems with this approach, though. For starters we wouldn’t be able to track any additional information easily (device UDID, geo-location, etc). Also if the row was locked by an existing query other queries to update the count could fail resulting in loss of data. More importantly, it would have rendered much of our existing data useless without writing a script to convert it.
Eventually I realized my whole idea of using COUNT in the first place was way off base. My thinking was that running a bunch of smaller queries returning minimal a amount of data was better than running one large query returning a ton of data that PHP would then have to sort through. The fundamental problem with this (which I only recently learned) is that COUNT is still running a SELECT statement to get the result (looking through the entire table and returning data). Doing this 60 times adds up especially since our table is hundreds of thousands of rows long. It’s also wasteful if nothing shows up for that query. So I modified the query to return all the data for the selected month and had PHP do the hard work instead:
Success! I was extremely happy to see such an improvement in execution time. In the next month we’ll see how this system scales up.