Read “Growing Tobacco in New Jersey (#1)” if you’re interested in reading about my first attempt at growing tobacco.

March 30th, 2011: Baby cotton in the front, tobacco behind.

The plants in the front of this picture are cotton and didn’t last long before being consumed by my cat. I wanted to make a cotton pouch for my tobacco.

The strongest plants are transferred to small pots. The strongest of these plants make it outside.

May 1st, 2011: The tobacco is old enough to go outside.

7 weeks. The tobacco goes outside when it looks hardy, which is usually after a couple weeks. The milk jugs give them protection while they get used to being outside.

June 9th, 2011: Young tobacco being chewed alive.

12 weeks. The soil in my wooden container has manure mixed in. I’m afraid of using pesticides.

June 21st, 2011: They're getting too big for the milk jugs.

Watching the plants outgrow the milk jugs is great. They’re riding a bike for the first time.

July 5th, 2011: The leaves are getting larger.

15 weeks. Tobacco grows quick. I fought the clovers in the background all summer.

July 19th, 2011: Still having bug problems, but overall doing well.

17 weeks. I still have bug problems in July. The top of the plant looks healthy, so a few sacrificial bug leaves are fine.

July 25th, 2011: Getting bushier.

The plant on the side is the orphan of the bunch. I reserved the back-left corner of the box for the only cotton plant that lived. The cotton plant was eaten by squirrels shortly after.

July 25th, 2011: I wanted to eat it.

The rain is almost frequent enough to keep the plants fed. Stressing the plants does them good, so I wait until the leaves start to droop before giving them water. The leaves perk up after an hour.

August 9th, 2011: The plants are thick.

22 weeks. The older leaves are getting their heft now. I’ve noticed that bugs tend to choose the same leaf to stick with, so I leave them around for the sake of the plant. They’ll only eat the leaf if it’s still attached. My decoy leaves never worked.

August 16th, 2011: They little one on the side was a crap-shoot anyway.

Seeing the plants cast shadows against the fence is a gratifying feeling.

August 26th, 2011: The leaves on the bottom are sacrificial.

24 weeks. This is the point in time where the plants really get their height. New leaves are cropping up every day. The new ones are at the top, pointing upward.

August 28th, 2011: The great storm. I used paint cans to help hold the roots down.

I’ve always known that storms are a nightmare for farmers, but never understood like I do now. Hurricane Irene hit New Jersey on the 28th, which is when I was forced to relocate to a friend’s house. I prepared the plants by placing heavy polyurethane cans at the roots. I also pushed the dirt down around the bases. A large tobacco plant is a boat with many sails.

August 29th, 2011: The plants were sad for days.

The storm passes. I push the roots back into the ground. The leaves drooped for days and the plants are now at a permanent angle.

September 12th, 2011: As tall as I am.

26 weeks. I stand at about 5’11″. The plants are taller than me within days.

September 27th, 2011: I don't know when to harvest.

Last year I pulled every leaf from my plants on November 3rd. This year I promised myself to let the plants live until they died, harvesting along the way. It’s an experiment.

October 18th, 2011: Embarrassingly proud of the flowers.

31 weeks. October was a beautiful month for me. My plants flowered for the first time. I have too many photos of every flower.

October 18th, 2011: Stripped the bottom leaves to give the top ones more power.

My sister gets her hair trimmed once a year to promote growth. I strip the bottommost leaves.

October 26th, 2011: The flowers!

The flowers alone make tobacco worth growing.

November 6th, 2011: You can see the poly cans from the great storm.

34 weeks. They’re at the point where I pulled them from the ground last year. The problem with growing tobacco in New Jersey is the duration and heat of summer. The leaves don’t get enough time to yellow. They end up drying badly and make terrible cigars.

November 13th, 2011: Worlds collide.

The plants are intertwined. Like a mother, I had unwavering hope for the orphan plant until this picture. Everyone knew but me.

December 4th, 2011: Tomorrow's plants are today's seeds.

38 weeks. I have seeds for this year that I am ready to plant! I plucked these down when they started falling from the plants. The leaves have been completely harvested and are hanging in the same shed as last year. I’m feeling ready to roll last year’s leaves into cigars at this point, and am beginning to plant the third harvest now.

You can see the full-sized photos in the gallery on Flickr at: Second year of growing tobacco in NJ

Logging In

The following command is part of the upload script and takes a username and password as parameters:

curl -L -s -c cookie \
-d email=$email \
-d password=$pass \
-d rememberme=0 \
-d process=1 \
-d submit=1 \
-d redirect=0 \
https://www.movember.com/us/auth/do-login

The first line passes three flags to curl: location (-L), silent (-s), and cookie (-c). Location will redirect your request if a redirect is seen. The silent flag suppresses the progress bar output, and the cookie flag lets you specify a file where cookie information is stored. The last part of the command sends the data (-d) in a POST request. The data flag lets you build a single string to pass instead, but I’ve opted to be more verbose here for clarity.

When someone logs in on Movember.com, they’re redirected with a “302 (Moved Temporarily)” request to their main page. We use the information on the user’s main page to figure out their ID number (Movember refers to this as the user’s “entity ID”). If we only needed the cookie file, we wouldn’t have to care about the redirect. (Note: the curl in the upload script pulls the entity ID into a variable and isn’t shown above).

We can see the redirect ourselves by adjusting the command above to include headers:

curl -is \
-d email=$email \
-d password=$pass \
-d rememberme=0 \
-d process=1 \
-d submit=1 \
-d redirect=0 \
https://www.movember.com/us/auth/do-login

The first line returns: HTTP/1.1 302 Found, which is the “Temporary redirect” mentioned earlier.

The last part of the command sends the necessary information to movember.com’s login form through a POST request. The form names are located within the page’s source. You’ll run into problems if you don’t submit all the information the form is expecting. Tamper Data for Firefox is a great tool for figuring out what exactly gets sent — turn it on, fill out the form, and examine the request being sent to the server. You can use this information to reconstruct the request with curl.

Uploading Images

Now we have a cookie file that we can use to authenticate ourselves to the server with. We’ll use the silent flag again and pass the cookie file in with the -b flag:

curl -s -b cookie \
http://us.movember.com/mospace/your-donation-page/create-post/
-F content=$new
-F entity_id=$entity
-F name=image
-F "filename=$new;image/jpeg;"
-F "image=@$new"

The rest of the request is very similar to the last request. Instead of using the data flag, we’ve switched to the form (-F) flag. You need to use the form flag if the form you’re posting to specifies that it’s multipart/form-data. It also allows you to upload binary files (in this case, a picture of a mustache). Here we’re posting a:

• status update – the name of the file so we can track our growth
• our entity ID – saved from the last request.
• the name of the content – in this case, Movember expects either “image” or “video”.
• the filename of the image
• the contents of the image – the ‘@’ symbol tells curl to pull the information from a file on disk.

That’s it! Are you participating in Movember? Are you running a Mac with Snow Leopard or Lion installed? Download the Movuploader DMG here or go to the Movuploader Github page.

1. Interesting/funny conversation happens in the channel.
2. Someone says !quote.
3. The bot messages the quoter with the last 13 lines of the conversation.
4. From here, the person can “keep” or “delete” specific lines, or chunks of lines.
5. Each action results in a paste of the edited conversation until the person is happy with the preview.
6. Person messages the bot with “go” and it shows up on the forum.

My bot already logs the conversation, so it just runs tail -n13 on the log file (prepending line numbers to the front) and sends a private message to the caller. The actual editing is a simple combination of regular expressions and array splicing. Editing continues until the user posts the message or quotes something new.

WWW::Mechanize makes posting the final message simple:

sub _postIt {
  my $message = shift;
  my $mech = WWW::Mechanize->new();
 
  # go to the login page
  $mech->get("http://forum.deadcodersociety.org/index.php?action=login");
  sleep(5);
 
  # submit credentials
  $mech->submit_form(
    with_fields => {
      "user"    => "stanbot",
      "passwrd" => "password"
    }
  );
  sleep(5);
 
  # grab the "Quotes" thread
  $mech->get("http://forum.deadcodersociety.org/index.php/topic,78.0.html");
  sleep(5);
 
  # grab the reply link and click it
  $mech->follow_link(text_regex=> qr/REPLY/i);
  sleep(5);
 
  # submit our new quote
  $mech->submit_form(
    with_fields => {
      "message" => "[quote]" . join("",@$message) . "[/quote]",
      "subject" => "Re: DCS Quotes!",
    }
  );
}

I added the calls to sleep because I was triggering the forum’s bot-detection code. The submit_form method is smart and will automatically detect the form based on the fields passed in. The channel is made aware of the post after it finishes since the bot scans for new messages posted to the forums.

We’ve had this for about two months now and it’s been used by everyone for nearly every quote. It encourages people to quote more conversations and ultimately strengthens the bond in the community. Pretty good for 33 lines of code!

This is a repost from the post I made over at the actual Dead Coder Society blog. The Dead Coder Society (DCS) is a group I formed this past year at Stockton. It’s a selective student-run group of dedicated computer science majors, with a goal of teaching each other interesting stuff they wouldn’t learn in class. I am convinced that the existence of DCS has improved my technical ability, social skills, and has gained me a network of incredibly smart people.

The First Year of the Dead Coder Society

The first year of the Dead Coder Society is over. We did an amazing number of things right for a first-year group:

• We met consistently. A consistent meeting schedule is critical for establishing trust in the group. Trust makes other members want to show up and want to present.
• We built a strong network of intelligent, enthusiastic students. Outside of learning from each other, a consistent schedule enforced us all to get to know each other better. One of the problems that most computer science majors at Stockton face is a lack of community. We tied community and learning to create strong bonds that have lead to job opportunities and more.
• We accomplished goals without a budget. We shared in any expenses that we incurred, and as a result, I think we all appreciated what we did more.
• We accomplished goals without official club status. We were free to meet where and when we wanted to, without needing to seek advisor approval or wait for funds to be processed. We weren’t forced to waste time writing a constitution or electing certain people to official positions. Our success was directly related to the work every member put in.
• We maintained a strong web-presence throughout the year. The Dead Coder Society has an up-to-date website, complete with forums and chat rooms. Every meeting has been logged and the slides are available for most speakers. Our log of activity is more up to date than most clubs at Stockton. We also experimented with advertising the Society through Google advertising and received several internship offers.
• We worked on school-wide educational projects. Outside of our schoolwork and extracurricular study, we embarked on smaller projects to directly benefit Stockton. There is an education resource project still underway internally, and there are plans for several programming competitions at Stockton.
• We kept other members up to date with video recordings of meetings and live Skype calls when available.Some members were unable to attend meetings, which typically would mean completely missing the educational and social value that comes from showing up. We recorded every meeting from the second half of the year and in some cases were able to live-cast the meeting directly to the missing member.

Three of our members (including myself) graduated this spring:

• Stan Schwertly
• Aniello Anthony DiSpigna
• Andrew Hofstetter

There will be some changes to the Society coming in the future, but until then:

Cheers to the Dead Coder Society,

Stan Schwertly

While I don’t share the exact level of hate of macports as him, I ended up using part of Matt Hutchinson’s excellent guide for Gource on OSX. Gource has a slew of options and allows you to generate videos from git repositories, as well as Mercurial, Bazaar, and SVN. I ended up removing files from the video, since it cluttered the screen. I also highlighted directories and users and scaled users to a size of 1.6. You can adjust the speed of the video too. Be careful though: it’s a fine line between flurrying and boring. You’re even able to specify images for each specific contributor if you choose to do so. There are several scripts available online that attempt to import gravatars based on the repositories configuration information.

Gource is a fun way of visualizing the work put into any repository. Every project that can be gource’d should be gource’d.

Another shout-out to Mike Greb for initially showing me Gource. Obviously none of this would have happened if he didn’t know about all of the cool things ahead of time.

• You use a Mac
• You use Taskwarrior
• You have “task list” dumped to a file accessable online (preferably through cron)

Background: I have a cronjob that pumps the output of “task list” to a text file every 5 minutes. The text file is under a web directory of mine, so I’m able to see my current list of tasks from any location with web-access. I wanted a dashboard widget that sucked in the text file and displayed it. I tried using “Web Clip”, but the bounding box is static — which means you’re either stuck with too big of a box, or your text gets cut off.

Features: Here’s a simple widget that lets you replace the URL with a text file of your own. It dynamically resizes the window to fit the text file. I don’t anticipate having a long task list and I don’t like scrollbars.

File: You can find the latest version of TextPuller on GitHub at: https://github.com/Stantheman/TextPuller

Let me know if you have any suggestions!

Update: TextPuller has been featured on Taskwarrior.org: http://taskwarrior.org/news/79

I learned a lot about working on a team and the software creation process. Here are a few of the points that stand out:

• Open communication early. Find out exactly what the user needs and which requirements are most critical.
• Communicate with everyone often. Stockton had a progress log that we posted updates to. Besides keeping everyone in sync, the progress log was a subtle “I should catch up” alarm. We had a leg-up over the other teams in that we all participated in an IRC channel together and otherwise we friends prior to the semester.
• Leverage technology to increase communication. We used GitHub’s post-receive hooks to send text messages and emails to each member of the team when someone pushed. There was no excuse for being out of the loop.
• Most of the actual work was finished when we weren’t together. Although a lot of the design was a result of our discussions, the bulk of our code was made by each individual member by themselves. We still programmed when we were together, but it became too easy to become sidetracked.
• Meetings in person help the design process. It was easy to talk about the benefits of one type of design in person. You can talk with your hands in person and use whiteboards in person. It’s perfect for discussing ideas.
• Spend time choosing your team members. It’s a lot better to go through one awkward rejection than to suffer through a semester of disappointment. This might not be applicable in all situations. If you can’t get rid of a slacker, try hard and fast to find something that fits their skill set. If that fails, talk to someone with more power than you.

I also learned that I should keep passwords out of git if I plan to release the code as open-source. A link to a working version of SHiGS (along with the code) will be made available as soon as I move any sensitive data to a config file that isn’t tracked in version control .

Baby Tobacco (April 24th, 2010)

I grew cigar tobacco for the first time last year. Planting tobacco is weird because the seeds need to lay on top of the soil, instead of being covered or buried.

Bushy Baby Tobacco (May 20th, 2010)

I had more seedlings than I could keep, so I pulled the stragglers out with tweezers. The remaining plants continued to grow until it was time to transplant them outside.

I built a 4′x4′ box for the plants to sit in. The plants had cut-off plastic milk jugs on top of them while their roots settled.

I used discount wood from Home Depot. The dirt was more expensive.

I put too many plants outside as insurance against failure. They succeeded, and the smaller plants began to take resources from the stronger ones.

This is what tobacco plants look like when they're too close together. (June 26th, 2010)

I needed to thin out the plants to give the stronger ones room to grow. I had no space to put the smaller plants, and ended up discarding them.

Toddler tobacco. (July 11th, 2010)

I didn’t use any chemicals on the plants. I ran my fingers against the leaves to stop bugs in problematic areas. Squirrels and birds stayed away from the plants.

I had five plants total. They started growing really quickly in July.

This was seven days later! (July 18th, 2010)

I was torn between two plants during the thinning process, so I filled a bucket with dirt and kept both.

The bucket plant actually did really well and was easy to move around. (July 21st, 2010)

The plants were still small in the beginning of August. I worried about the seasons changing.

The leaves are more matured at this point, but are nowhere near their full potential. (August 4th, 2010)

The August heat fixed everything.

They're not the tallest plants in the world, but they're much closer to being ready. (August 24th, 2010)

There are a few tidbits to know about growing tobacco:

• Little leaves will sprout off at the top of the plant. These “suckers” should be plucked off, since they won’t mature and will only remove energy from the important leaves.
• A leaf will begin to yellow slightly when it’s ready to be picked. The leaf will snap off if it’s ready to be plucked.
• Plucking the small lower leaves is good — the goal is let the large leaves grow as big as possible.

The bucket plant began to wilt in August. It stopped wilting in September.

The guesses are either root rot or overwatering. (August 28th, 2010)

I pulled off a majority of the leaves in early September. I took this picture after pulling a big group of leaves (which has since become the little image on the right-side of this blog.)

Stan and Tobacco (September 6th, 2010)

The plants were almost completely bare at this point, but lived and continued to produce suckers. I decided to battle them out of the ground in November.

I won. (November 3rd, 2010)

I hung the leaves in bundles. They’re still drying now. I’ll roll them into cigars the same way I did when I made them the first time.

The leaf is drying in a shed right now.

I threw the plants in the shed too (which is known as “whole-stalk harvesting”.) I’m starting this year’s crop now in hopes of getting larger plants. I’m trying cotton this year too, and will post about that in the future.

It’s much different than R. My previous use case for R was generating graphs, which is a small subset of the capabilities R provides. For example, R needs a datafile filled with data for analysis, where gnuplot only wants data that is pertinent to graphing. As a result, I needed to change my MySQL queries to be conscious of the fact that gnuplot only wants what it absolutely needs.

My first goal was to make a pie chart with gnuplot, but it’s not possible according to their FAQ. So I scratched that idea and made a histogram/barchart instead using the data pulled from a set of Perl scripts I wrote a while ago:

Also known as a histogram

The code for this is pretty painless and can be done through either gnuplot’s interactive shell, or through scripting. If you’re running it interactively and want to save the output, be sure to run “save ‘filename.plot’” before exiting:

#!/usr/bin/gnuplot -persist
set terminal png nocrop font small size 640,480
set output 'barchart-openmic.png'
set style data histograms
set title "Most Active Sections Of NJ CL for Open Mics"
set xlabel "CL Section Name"
set ylabel "Post Count"
plot "/tmp/bargraph.csv" using 2:xticlabels(1) notitle

It’s also interesting to note that the “plot” function takes a lot of parameters — the above code could be much shorter. I wanted to see the increase in activity on CraigsList over time, so I made a second graph. A few slight changes to the code pumps out a basic line graph. It actually took me longer to get the SQL query right than to put the code down (both quick though!). The primary change was the “set style” line, which became “set style data linespoints”. The result was exactly what I was hoping for:

Profits are up!

That’s it! gnuplot is great for simple graphmaking. I’ve got a cronjob set up that points to a simple bash script that runs the SQL query, then gnuplot, and then the “rm” on the file. It’s automatic graphing:

pull data -> dump data -> graph data

I’m looking forward to creating some of the more complex charts that I saw on the Wikimedia page and eventually using them to help revitalize JerseyMic. More about the JerseyMic project later!

(Interested in getting started? Math-blog.com has a pretty great post on the topic!)

This is a side-post cut out of “Using R to Automatically Generate Pie Charts“. I enjoyed talking about the architecture behind making the graphs, but the specific hurdles I hit with MySQL were overwhelming and detrimental to the overall point: simple automated graph generation. I hit three hurdles getting MySQL to work with my automated pie graphs:

1) Dumping a table with the column names on the top row.

2) Having the root user perform these tasks without placing the MySQL password in the cronjob.

3) Dumping the data to the same location through a cronjob.

Dumping the table with column names:

Dumping a CSV file is easy to do, and can be accomplished using a simple MySQL query or by using the mysqldump utility. I figured I’d start with the mysqldump utility since I didn’t want to store my password in a cronjob (which was fixed later.) I wanted the column names to be on the first row in order to have R know the table information.  I had a line working with mysqldump that would dump the data to CSV, but couldn’t get the column names included in the first line. Mysqldump will not dump a CSV file with the column names in the first row.

I ended up using a cronned MySQL query that dumps a CSV file. There are many different examples of this syntax online, but fewer for dumping the columns as well (specifics shortened up:)

mysql -u root -e “SELECT ‘id’,'title’,'url’,'section’ UNION SELECT id,title,url,section INTO OUTFILE ‘/tmp/result.csv’ FIELDS TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘\”‘ ESCAPED BY ‘\\\\’ LINES TERMINATED BY ‘\n’ FROM db.table;”

The part before the “UNION SELECT” will specify the first row that gets sent to the file; these are your headers. I have a small amount of information to dump to the file, so I hard-coded the column names.

Saving the user password to a configuration file

Having the correct SELECT query didn’t help, because I didn’t want to put my password in the plaintext of the cronjob. StackOverflow came to the rescue, and a few minutes later I had a configuration file for the MySQL user:

http://serverfault.com/questions/56341/mysqldump-prompting-for-password-in-shellscript/56345#56345

User Zoredache explains the reason behind doing this perfectly by saing, “…having it in the command line [would allow] anyone who can run ps find the password for your server.” After creating this file, a simple “chmod 600″ ensured that the contents of the file would remain secured.

Dumping the data to the same location nightly and OUTFILE syntax

I thought I’d change the path to something other than /tmp before realizing the MySQL needs permission to write to the directory. After getting the query correct, I ran it. My intentions were to have this run each night (or week, or month) and have the previous file overwritten. The OUTFILE syntax doesn’t allow for the overwriting of files though:

The SELECT ... INTO OUTFILE 'file_name' form of SELECT writes the selected rows to a file. The file is created on the server host, so you must have the FILE privilege to use this syntax. file_namecannot be an existing file, which among other things prevents files such as /etc/passwd and database tables from being destroyed. (http://dev.mysql.com/doc/refman/5.0/en/select.html)

This one was simple: I added a cronjob that would “rm” the old CSV file once the R script finished.

Finish the rest of the post at: Using R to Automatically Generate Pie Charts