Sublime Text 2 Grunt Build
Kick off a grunt build from within Sublime Text 2:
{
"cmd": ["grunt"],
"working_dir": "/Users/[your username]/[your project path]",
"shell": true
}
It took me a bit to figure out how to actually make a grunt build run from within SublimeText 2, so I wanted to capture it here for anyone else trying to figure it out. Google really didn't help me at all...
The key is the working directory thing. You can't use "~/", you have to actually use the full path to your directory that you normally kick your grunt builds off from. I found one place on stackoverflow where it recommended adding this after "grunt":
, "--no-color"
but it didn't change the output for me at all.
You put this code in a file you create by clicking "tools" > "build system" > "new build system". Then whatever you name the file when you save it will be the name of the "build system". You can hit "cmd B" to build it or select "tools" > "build system" > "whatever you named it"
Slider Video Embed
If you are looking to embed video into the slider using the continuum refactor, here's how:
1) Go to the video on Youtube or Vimeo
2) Copy the "<iframe..." portion of the embed code
<iframe src="http://player.vimeo.com/video/44143357" width="500" height="356" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
3) Create a new post/review
4) Create a custom field named "vimeo", "vimeofull", "youtube" or "youtubefull"
5) Paste the embed code into the custom field
6) Adjust the size the video displays at (width should be around 460 and height should be around 340 for "slider A")
7) Tag the post/review with the tag "spotlight"
Note: There is currently a bug with the slider that causes it to continue rotating while the video is playing. This will be resolved by 9/15/12. Bug has been fixed and is no longer present in v12.0918. However, slider will only pause while your mouse is over it. Working on another change to make it so that the slider will pause once you start playing a video and will unpause only once you interact with it again.
dynode Batch Get Item
Working a lot with node.js, dynode and dynamoDB recently. Still trying to wrap my head around it all. Had a horrible time getting dynode.batchGetItem to work. Here is the error I was getting:
{ name: 'AmazonError',
type: 'ValidationException',
serviceName: 'com.amazon.coral.validate',
message: 'One or more parameter values were invalid: Mismatching attribute types between location and schema',
statusCode: 400,
retry: [Getter] }
Basically it came down to that the range selector I was using was being passed through as a string instead of a number. This is *even though* I am chaining queries, having just gotten the range selector out of another table and am immediately using it in the query that is failing. The way I was able to fix it was by casting it from a string into a number (the way Amazon expects it to come across):
results.Items.forEach(function(element, index, array){
console.log(element);
element.events.SS.forEach(function(ielement, iindex, iarray){
var batchVars = {"events": {keys:[ {hash: ielement, range: parseInt(element.timestamp.N)} ]}};
dynode.batchGetItem(batchVars, events.debugOutput);
}, query);
}, query);
The crucial part here being this line:
{keys:[ {hash: ielement, range: parseInt(element.timestamp.N)} ]}
Note the "parseInt" function there that gets run on the timestamp that was pulled out of the previous query results. That's the key to getting this to work.
UPDATE:
The dynode author asked me to submit an issue, so, I did!
https://github.com/Wantworthy/dynode/issues/18
I had just assumed this was a quirk of the library. I feel way too new to all of this to know what is a bug and what is just me doing something stupidly...
WP phpBB Bridge: Warning: mysql_set_charset() expects parameter 2 to be resource, boolean given
Warning: mysql_set_charset() expects parameter 2 to be resource, boolean given in wp-content/plugins/wp-phpbb-bridge/inc/widgets/wpbb_topics_widget.php on line 149
This is an error caused by the fact that the WP phpBB Bridge plugin is naively written in places.
For instance, in this case the plugin authors don't expect you to be using a socket instead of a port. Looking at the documentation for mysql-pconnect you see that you can either use combination of hostname:port or hostname:socket. Since they are pulling the setup info straight from the phpBB config file, you have little to no control over the values there (especially if already configured).
What they ought to do is check to see if $port isset() && !empt() and only then append the ":" . $port. But instead, they tag on ":" to your db host EVERY TIME. This breaks your setup if you host is defined in phpBB with a socket. Most of what I just said sort of sounds like gibberish even to me, so, basically, if you are getting this error, the problem is actually line 147. Replace the current line 147 with this:
Events Calendar Pro Nav Formatting Messed up on Empty Calendar
The Events Calendar Pro (from http://tri.be/) has a few problems.
If you are trying to figure out why a calendar with no events in that month has completely screwed up header navigation, just put this line of code inside of table.php in the top of the display_day function (put it directly before the for loop):
$thisisherebecausethispluginSUCKSdontremoveit = has_excerpt() ? TribeEvents::truncate($post->post_excerpt) : TribeEvents::truncate(get_the_content(), 30);
This basically just runs some "truncate" function on the "TribeEvents" object. For some reason this truncate function magically fixes the header nav display issues.
WordPress Settings API – Adding Options to Existing Page
Adding new options to an existing page in the dashboard in wordpress can be maddening. I've literally spent 15+ hours dealing with this horrible API at this point. To the point where I wrote two different wrappers for it.
Here are some notes chiseled along the way for any poor soul following me down this obtuse path.
Today I'll focus on adding options to an existing page. Hopefully soon I'll do one on making a new page.
Checklist/Overview:
1. Hook into the admin init action (add_action('admin_init'))
2. Create your section (add_settings_section)
3. Output hidden fields so settings will save (settings_fields)
4. Create your fields (add_settings_field and register_setting)
Your options will be available through the usual "get_option" means...
Step 1) Hook into the admin init action:
Step 2) Create your init function (that you just hooked into the admin_init action):
Step 3) Create your own section register API
Step 4) Create your section callback functions
It is really annoying that the API doesn't allow you to pass params to this callback function, which means you have to define each one individually...
Step 5) Create your own field register API
Step 6) Create your global callback function
Step 7) Register your section(s)
This goes in that init function you made in step 2
Step 8) Register your field(s)
This goes in that init function you made in step 2
Here's an example of a completed version of all this. This one adds a crap ton of custom thumbnail size options to the media panel. It is a really bad example as it is overly complex:
Using two different identity files with ssh for rsa remote authentication keys
I have two different servers I need to connect to, each requiring two different types of remote authentication keys. One requires rsa, the other dss. So I had to make and use two different remote authentication keys, but was unsure as to how to tell my machine to serve them both up. It was, by default, just serving up the rsa key.
What I had to do was create a file called "config" (NO file extension) in the ~/.ssh directory on my machine. I then put two lines in this file:
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dss
It works like a charm.
For the curious, I'm on windows using the git bash that comes built in with git (NOT cygwin). My ~/.ssh directory looks like this:
I generated these RSA keys with a command similar to this:
ssh-keygen -t dss -f ~/.ssh/id_dss
And copied and pasted the contents of the id_rsa.pub (and id_dss.pub) files into the appropriate place (something like ~/.ssh/authorized_keys) on the remote servers.
Creating ATG Droplets and serving a default oparam
Creating your own ATG droplets is not difficult. Servicing a default open parameter (oparam) in an ATG droplet is surprisingly extremely easy.
ATG has these things called "droplets" that you use from within your "dsp" tag library. You can --nay-- you SHOULD make your own droplets. You should have as little Java code in your JSP pages as humanly possible.
To do this takes a few steps:
-
Create the .java file
Create it under /modules/base/src/java/com/yourlibrary/
-
Extend "DynamoServlet"
The inside of your Java file should look something like this (to begin):
package com.yourlibrary;import java.io.IOException;
import javax.servlet.ServletException;
import atg.nucleus.naming.ParameterName;
import atg.repository.*;
import atg.servlet.*;public class YourDroplet extends DynamoServlet{
@Override
public void service(DynamoHttpServletRequest request, DynamoHttpServletResponse response)
throws ServletException, IOException
{
}
} -
Create the .properties file
Create it under /modules/base/config/yourlibrary/
-
Define your properties
$class=com.yourlibrary.YourDroplet
$scope=global
$description=For documentation purposes only
global scope makes it so there is only 1 instance of the droplet per JVM. You can do session or request scope as well. This is all server admin magic voodoo. I can give you no recommendations here, that's a topic for it's own entire post
-
Implement the droplet
Create a jsp page somehwere (probably something like /modules/base/j2ee-apps/base/web-app.war) if you haven't already, and then add this code:
<%@ taglib uri="/dspTaglib" prefix="dsp"%>
<dsp:importbean bean="/yourlibrary/YourDroplet" />
<dsp:page>
<dsp:droplet name="YourDroplet">
</dsp:droplet>
</dsp:page>
OK, at this point you have the skeleton for your droplet created. Go ahead and burn incense, sacrafice a chicken and compile and run and see if it worked. If not, don't ask for help here, I'm just a poor Java hating front-end dev trying to document an insane procress. Go to StackOverflow.com instead.
Now, let's make it serve a purpose. Let's say you just want, like, the user name or something:
Your .java file
package com.yourlibrary;
import java.io.IOException;
import javax.servlet.ServletException;
import atg.nucleus.naming.ParameterName;
import atg.repository.*;
import atg.servlet.*;
public class YourDroplet extends DynamoServlet{
@Override
public void service(DynamoHttpServletRequest request, DynamoHttpServletResponse response)
throws ServletException, IOException
{
String username = null;
username = "do whatever you have to do to get the username and put that here";
request.setParameter("username", username);
request.serviceLocalParameter("ousername", request, response);
}
}
Your .jsp file
<%@ taglib uri="/dspTaglib" prefix="dsp"%>
<dsp:importbean bean="/yourlibrary/YourDroplet" />
<dsp:page>
<dsp:droplet name="YourDroplet">
<dsp:oparam name="ousername">
<dsp:valueof param="username" />
</dsp:oparam>
</dsp:droplet>
</dsp:page>
Now, let's say that some of your users are admins, and in some places you want to have a special thing that happens when the user is an admin, but in others, just the normal thing happens no matter what. You can use a default for this. Here's how:
Your .java file
package com.yourlibrary;
import java.io.IOException;
import javax.servlet.ServletException;
import atg.nucleus.naming.ParameterName;
import atg.repository.*;
import atg.servlet.*;
public class YourDroplet extends DynamoServlet{
@Override
public void service(DynamoHttpServletRequest request, DynamoHttpServletResponse response)
throws ServletException, IOException
{
String username = null;
boolean handled = false;
boolean isadmin = false;
username = "/*do whatever you have to do to get the username and put that here*/";
isadmin = /*find out if they are admin and set this boolean]*/;
request.setParameter("username", username);
if(isadmin){
handled = request.serviceLocalParameter("oadmin", request, response);
}
if(!handled){
request.serviceLocalParameter("ouser", request, response);
}
}
}
Your .jsp file
<%@ taglib uri="/dspTaglib" prefix="dsp"%>
<dsp:importbean bean="/yourlibrary/YourDroplet" />
<dsp:page>
<!--Special case for admin-->
<dsp:droplet name="YourDroplet">
<dsp:oparam name="oadmin">
Admin <dsp:valueof param="username" />
</dsp:oparam>
<dsp:oparam name="ouser">
<dsp:valueof param="username" />
</dsp:oparam>
</dsp:droplet>
<!--No special case for admin, admin falls back on ouser-->
<dsp:droplet name="YourDroplet">
<dsp:oparam name="ouser">
<dsp:valueof param="username" />
</dsp:oparam>
</dsp:droplet>
</dsp:page>
You can take this to any level you want. Here is a more complex basic example:
Your .java file
package com.yourlibrary;
import java.io.IOException;
import javax.servlet.ServletException;
import atg.nucleus.naming.ParameterName;
import atg.repository.*;
import atg.servlet.*;
public class YourDroplet extends DynamoServlet{
@Override
public void service(DynamoHttpServletRequest request, DynamoHttpServletResponse response)
throws ServletException, IOException
{
String username = null;
boolean handled = false;
boolean isadmin = false;
boolean ismoderator = false;
username = "/*do whatever you have to do to get the username and put that here*/";
isadmin = /*find out if they are admin and set this boolean]*/;
ismoderator = /*find out if they are mod and set this boolean]*/;
request.setParameter("username", username);
if(isadmin){
handled = request.serviceLocalParameter("oadmin", request, response);
}elseif(ismoderator){
handled = request.serviceLocalParameter("omoderator", request, response);
}else{
handled = request.serviceLocalParameter("ouser", request, response);
}
if(!handled){
request.serviceLocalParameter("default", request, response);
}
}
}
Your .jsp file
<%@ taglib uri="/dspTaglib" prefix="dsp"%>
<dsp:importbean bean="/yourlibrary/YourDroplet" />
<dsp:page>
<!--Each special case is used-->
<dsp:droplet name="YourDroplet">
<dsp:oparam name="oadmin">
Admin <dsp:valueof param="username" />
</dsp:oparam>
<dsp:oparam name="omoderator">
Moderator <dsp:valueof param="username" />
</dsp:oparam>
<dsp:oparam name="ouser">
User <dsp:valueof param="username" />
</dsp:oparam>
</dsp:droplet>
<!--No special case for admin or moderator, they fall back on default-->
<dsp:droplet name="YourDroplet">
<dsp:oparam name="ouser">
User <dsp:valueof param="username" />, you are not permitted here. Begone!
</dsp:oparam>
<dsp:oparam name="default">
Welcome <dsp:valueof param="username" />. Access granted!
</dsp:oparam>
</dsp:droplet>
</dsp:page>
Updates – BASIC jquery ui tabs rotate documentation, a note on nodejs hosting, and a note on the re-design
nodejs, jquery ui tab rotate, and re-design. Just a few quick notes...
-
I'm actively working on documentation for the jquery ui tab rotation plugin. I've (finally) got a very basic working example up.
The plugin is stupidly easy to use:
$("#tabbedElement").tabs().tabs("rotate", 4000, true);
Note that you MUST first call tabs() before you can add the rotation with .tabs("rotate", [ms], [rotate]). Also note that as of right now none of those params are optional! You can also call .tabs("pause") and .tabs("unpause") to start and stop the rotation. You can instantiate a rotating element that starts as "paused" by passing in false for the [rotate] param.We use this plugin at FinishLine.com, and we are always on the most recent stable release of both jquery and jquery UI, which means that this plugin is nearly always guaranteed to work with the newest version of both. I'll be posting updates to this blog whenever there is anything to report. The plugin's official "homepage" is right here.
-
Node.JS is a server side implementation of JavaScript. It is basically PHP or ASP or [name your server side language of choice here] but with JavaScript. This fulfills Knuth's 3rd law, which states that any code that can be written will eventually be written in JavaScript, which fulfills Knuth's 4th law which states that Knuth's 3rd law will change languages every 10 years. In case you were wondering, Knuth's 2nd law is that a 12% improvement is easily obtainable and should not be marginalized, which compliments while nearly contradicting Knuth's 1st law, which states that premature optimization is the root of all evil.
ANYWAYS, I'm working on something FUN in node.js. If it works out, it's gonna be BIG. If not, you'll never hear about it again, lol. But that's not what I want to talk about. This is a quick note to make mention of the fact that if you are looking for a node.js server, they are out there. You don't have to roll your own. Check out no.de, or this stackoverflow question or this page on the project's wiki for hosting options.
-
And last but not least, you may notice that I have re-designed the blog. I'm now using a PREMIUM wordpress theme created by my good friends over at outerspiceweb.com. It's called Continuum, and it is spectacular. It is their newest offering.
I'm doing some work with it, so I installed it here to help me figure out how it works and debug and develop on it, but I like it so much I think I'll just leave it up. You too can have this rad-tacular theme by heading over to its page on themeforest.
- Oh, and one final thing. I am actually working on upgrading status-bar calculator for Firefox 4.0. I'm having trouble, I have no idea why it's not working, but when I figure it out there will be a write-up here.
Making Git show post-receive e-mails as an HTML color formatted diff
I wanted git to send me an e-mail with a color formatted HTML diff view of pushes/commits whenever the remote server received a push. After some digging I found that I could accomplish this using the post-receive email hooks in combination with Pygment's command line tools (using Python).
Prerequisites:
I will assume for this post that you have Git, Python and Pygments installed. It's been months since I installed Pygments, and I honestly can't remember *anything* about installing it, which means it was probably pretty straightforward and easy. You probably can just do this from your shell:
sudo easy_install Pygments
Making your Git repo send colored diff e-mails:
1. Setting up the post-receive hook
a. post-receive
The first thing you will need to do is configure your post-receive hook:
/git/your-repo.git/hooks/post-receive
In the hooks directory (cd /git/your-repo.git/hooks/) there will probably already be a "post-receive.example" file. Just copy it and rename it post-receive.
This file is basically a shell script. It is run after your repo gets a push and is updated. It is passed in 3 arguments: old revision hash, new revision hash, refname
All you really need to put in this file is the following line:
. ~/git-core/contrib/hooks/post-receive-email
What this does is calls another shell script "post-receive-email" and passes along the arguments (I think).
I'm pretty sure you could specify other shell scripts in the same way at this point if you wanted to.
b. post-receive-email
Now make the file you referenced from the post-receive file:
Move to your global hooks directory (the other one you were just in was specific to just that one repository, this one is the global hooks dir):
cd ~/git-core/contrib/hooks/
Create a file called post-receive-email. This is a shell script, but DON'T put ".sh" on the end.
Now, place the following code in that file (or, better yet, here's the file):
I'll try and point out some of the relevant portions of this script:
generate_email_header() (line 198):
This is the header of the e-mail, including the subject as well as the first few lines of the e-mail.
You may notice some variables here. ${emailprefix}, $projectdesc, etc. I'll talk a little about these later on.
Basically, what you need to know here is that if you want to change the e-mail subject or the beginning content of the e-mail, you do that here. You *could* hard code the recipients here, but don't. We'll talk more about recipients later.
generate_email_footer() (line 219):
This is the footer of the e-mail.
Notice that I placed a line here that tells you which files are causing these e-mails to be sent. I highly recommend keeping this line so that whenever you want to change anything about the e-mail, the e-mail itself tells you everything you need to know about doing so.
show_new_revisions() (line 605):
This is triggered if someone pushes up new revisions that have not ever been pushed up before. This way each code change will only be shown in one e-mail ever. This is the part that generates the actual diff itself and this is probably the single more important part oft his blog post. Lines 635 through 638:
git show -C --pretty=format:"committer: %cn%ncomments: %N%n%s%n%b" $onerev > gitlog.txt
export PYTHONPATH='/usr/local/lib/python2.4/site-packages'
pygmentize -O noclasses=True -f html -l diff gitlog.txt
pygmentize -O noclasses=True -f html -l diff -o gitlogemail.html gitlog.txt
Let's break it down line by line:
1. This is the actual git diff. If you just plop this down in your command line right now (minus the > gitlog.txt part) and replace $onerev with a sha1 hash from your log, you'll see a "preview" of how your e-mail will theoretically look. Here's some code for you to try to see what I'm talking about, do the following in your shell:
git log
Copy one of the sha1 hashes shown the log, then...
git show -C --pretty=format:"committer: %cn%ncomments: %N%n%s%n%b"
(so, for example, and don't try using this exact line because you won't have my sha1 hash in your repo so it won't work):
git show -C --pretty=format:"committer: %cn%ncomments: %N%n%s%n%b" 583038808efbde6fef4eb2e92dd2a920ba714eed
(hit "q" to get out of the diff view this throws you into)
If you don't like anything about this diff view, you can change it by editing the format:"...." part. See the git-show page in the git manual for details.
LOGBEGIN (line 656):
This is a constant (it's counterpart is LOGEND on the next line). The contents here will be used in the script in various places. It's content is placed before the diff to help separate the diff from the rest of the e-mail.
recipients (line 676):
You *could* hard-code e-mail recipients here, but DON'T, we'll once again talk about this in just a few moments...
emailprefix (line679):
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
This specifies the text you want showing up right before the subject of the e-mail. It pulls in a setting from your gitconfig (again, we'll talk about this in a moment) but it also specifies a default in case you don't have one set. I make all my e-mails subject lines prepend with [GIT] so I know it's an automated git e-mail at a glance.
custom_showrev (line 680):
This line currently doesn't do what it looks like it does. At first line it appears that you can set your diff settings here, but this is actually unused at the moment. I was trying to make it so you could set your git-show settings in the git config, but I was having trouble getting it to work and gave up because I had bigger better fish to fry... So, don't be fooled into thinking you can change this line and have your e-mails be effected.
2. Setting your git config options
In the post-receive-email file, there were several variables that I kept saying I would talk about later. Now's the time!
We are going to set the variables in your git-config. I'm not 100% sure, but I suspect that this will allow you to have different settings per repository.
The way you do this is:
Move to your repository's home directory:
cd /git/your-repo.git/hooks/
At this point, you can dive right in and make new config settings, or you can list current settings. List current settings like this:
git config --list
To add new config settings:
git config --add blah.blah true
or
git config --add blah.blah "that is soo true dude"
or, better yet, just pop open the .git/config file in a text editor (git config -e) and add lines like this:
[blah]
blah = that is soo true dude
hooks.mailinglist
Whatever you put here will go in the "To:" field. (This is who the e-mail will be sent to).
git config --add hooks.mailinglist "ralphie@gmail.com, frank@gmail.com, steve@gmail.com"
Don't be fooled by the similarly named "hooks.announcelist" which, as far as I can tell, does nothing (theres a few lines of code that may use this if it isn't empty, but I haven't looked into this very far. Don't set it and it won't negatively effect anything. If you do set it, you may get unexpected results).
hooks.emailprefix
This is the text that will be inserted before the subject line. I like to set mine to [GIT] so I know it's an auto generated git e-mail by just glancing at the subject. If you don't set it, it defaults to [SCM].
git config --add hooks.emailprefix=[GIT]
Testing
Ok, at this point, you should be all good to go. Make a code changes, commit, push to your remote and sit back and wait on the e-mail.
Problems? I probably won't be able to help, but I'll try. Better to try asking on StackOverflow.com.
Good luck!
Pages
- Projects
- The History of the World (as relevant to Christopher McCulloh)
- WordPress Themes
- Continuum Refactor
Categories
- autobiographical
- flash games
- hardware
- history
- iPhone App Development
- Java
- Javascript
- math & physics
- movies
- n342
- plugin
- programming concepts
- project management
- prototyping
- screencast
- Software
- Theming
- Tools
- TOTW
- tutorial
- Uncategorized
- Usability
- video games
- web sites
- Wordpress
Blogroll
Archive
- February 2013
- September 2012
- July 2012
- May 2012
- April 2012
- December 2011
- November 2011
- October 2011
- May 2011
- January 2011
- November 2010
- October 2010
- September 2010
- August 2010
- June 2010
- May 2010
- April 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- August 2009
- July 2009
- June 2009
- February 2009
- October 2008
- September 2008
- July 2008
- June 2008
- May 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- June 2007
- November 2006