So, I’ve never dabbled in C until now while using it with AVR microcontrollers – and while trying to complie a simple for loop:
for (uint8_t bit = 0x80; bit; bit >>= 1) {
...
}
I got this error:
error: 'for' loop initial declaration used outside C99 mode
and to fix it I would move my decloration of the varabile outside of the loop. This seemed stupid to me so a quick Google search turned up this
Back in the old days, when dinosaurs roamed the earth and programmers used punch cards, you were not allowed to declare variables anywhere except at the very beginning of a block.
Solution was to add -std=c99 to the Makefile. My new AVR Makefile now looks like this..
Posted: June 15th, 2011 | Author: jay | Filed under: Code, Electronics | Tags: attiny, avr, avr-gcc, c, c99, gcc, makefile | No Comments »
This was what I needed for a rainbow RGB LED cycle…
Posted: May 10th, 2011 | Author: jay | Filed under: Code | Tags: attiny, attiny85, avr, led, rainbow, rgb, sin, sine, sine wave | No Comments »
Based on Atmel’s AVR136: Low-Jitter Multi-Channel Software PWM Application note, here’s a 3 channel software-based pulse width modulator to drive a RGB LED. This is a proof of concept and currently there is some in-efficient color cycling code in there, but the goal is to drive these cheap chips using an I2C (two wire serial) bus. Disco dance floor anyone?…
Posted: May 4th, 2011 | Author: jay | Filed under: Code, Electronics | Tags: atmel, attiny, attiny85, c, i2c, led, pulse width, pwm, rgb | No Comments »
This is what I’m using as a Makefile – based on what was included in a downloaded XCode template project – Can’t remember where I downloaded the starting point, but thanks…
Posted: April 26th, 2011 | Author: jay | Filed under: Code, Electronics | Tags: attiny, avr, make, makefile, usbtiny | No Comments »
Yeah, it’s simple but useful. Since I’m using sqlite at the moment, it’s just a copy but you could run any command in a similar way. I’m also tagging the backup name with a date. Here’s a snip from my Capistrano deploy file….
# ...snip...
namespace :deploy do
task :restart do
t=Time.now
run "cp /path/to/db.sqlite3 /path/to/backup/#{t.year}-#{t.month}-#{t.day}_#{t.hour}:#{t.min}:#{t.sec}_db.sqlite3"
run "touch #{current_path}/tmp/restart.txt"
end
end
Posted: May 20th, 2010 | Author: jay | Filed under: Code | Tags: backup, capistrano, database, db, deploy, sqlite | No Comments »
This MOSTLY is working, so, here’s what I found when trying to connect to Facebook with OAuth. It needs some serious refactoring because a lot of this was done in an “investigative” trial and error way. It also looks like Facebook have improved their docs on this since I was first looking at them…
First, you need to initiate a connection:
get '/:blog_name/facebook/oauth/create' do
redirect "https://graph.facebook.com/oauth/authorize?client_id=##FACEBOOK API KEY##&redirect_uri=##CALLBACK URL##&scope=publish_stream,user_status,user_photos,user_about_me"
end
where ##FACEBOOK API KEY## = your applications API key (mine is a 32 digit hex value) and ##CALLBACK URL## = the URL that will be processing the next step. Also, the scope value let’s you get more access to the user’s account. Check their extended permissions doc for more info.
Next, you need to process what comes back from Facebook. I am stashing what comes back in the DB (the FacebookOauthToken model). Also using the Mechanize gem which is pretty silly. Some of the code below is specific to my app, so ignore those bits…
get '/:blog_name/facebook/oauth/callback' do
if !params['code'].blank?
url="https://graph.facebook.com/oauth/access_token"
client_id="client_id=##CLIENT ID##"
client_secret="client_secret=## CLIENT SECRET ##"
code="code=#{URI.escape(params['code'])}"
redirect_uri="redirect_uri=http://example.org/#{@blog.url_name}/facebook/oauth/callback"
url="#{url}?#{client_id}&#{client_secret}&#{code}&#{redirect_uri}"
begin
res=open(url)
rescue
flash[:error]="There was a problem connecting to Facebook"
redirect "/#{@blog.url_name}/"
end
read=res.read
access_token=CGI.parse(read)['access_token']
if !access_token.blank?
@blog.facebook_oauth_token = FacebookOauthToken.new(:access_token=>access_token,:blog_name=>params[:blog_name])
if @blog.save
begin
a=Mechanize.new
res=a.get("https://graph.facebook.com/me/?access_token=#{access_token}")
@blog.facebook_oauth_token.facebook_id=JSON(res.body)['id']
@blog.save!
rescue
flash[:error]="There was a problem getting information from Facebook"
redirect "/#{@blog.url_name}/"
end
flash[:notice]="Facebook connection created!"
redirect "/#{@blog.url_name}/"
else
flash[:error]="There was a problem saving Facebook connection"
redirect "/#{@blog.url_name}/"
end
else
flash[:error]="There was a problem making Facebook connection"
redirect "/#{@blog.url_name}/"
end
else
flash[:error]="There was a problem connecting to Facebook"
redirect "/#{@blog.url_name}/"
end
end
Where ##CLIENT ID## = your Application ID (mine is a 12 digit numeric value) and ## CLIENT SECRET ## = your Application Secret (mine is a 32 digit hex value).
Once you have an access_token you should be able to make calls to URLs like this:
"https://graph.facebook.com/me/?access_token=#{access_token}". The /me path is the connected user’s data and I’m grabbing their Facebook ID from the returned JSON for use elsewhere.
Posted: May 20th, 2010 | Author: jay | Filed under: Code | Tags: access token, api, client id, facebook, graph, graph.facebook.com, json, oauth | 1 Comment »
Pretty simple, but wanted to log here so I can look this up in the future…
I wanted to deploy to both a stage and a live site. Here’s how that went down:
First I installed the capistrano-ext gem. Second, I edited my Capfile to look like this:
1
2
3
| require 'capistrano/ext/multistage'
set :default_stage, "beta"
set :stages, %w(beta live) |
Third, I created a deploy folder and added my two recipes there. beta.rb looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| load 'deploy' if respond_to?(:namespace) # cap2 differentiator
default_run_options[:pty] = true
# be sure to change these
set :user, 'username'
set :domain, 'beta.example.org'
set :application, 'fundastache'
# the rest should be good
set :repository, "#{user}@#{domain}:git/#{application}.git"
#set :repository, "/home/#{user}/git/#{application}.git"
set :deploy_to, "/home/#{user}/#{domain}"
set :deploy_via, :remote_cache
set :scm, 'git'
set :branch, 'master'
set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false
server domain, :app, :web
namespace :deploy do
task :restart do
run "touch #{current_path}/tmp/restart.txt"
end
end |
The live recipe looks almost identical.
Now when I
the site is deployed to the live environment and when I
or simply
the site is deployed to the beta site.
Posted: April 23rd, 2010 | Author: jay | Filed under: Code | Tags: beta, capistrano, deploy, production, recipe, stage | No Comments »
1
| curl -i -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{"user":{"username_or_email":"username","password":"password"}}' http://fas/test_json_post |
Posted: April 4th, 2010 | Author: jay | Filed under: Code | Tags: application/json, bash, curl, json, post, test | No Comments »
I’ve been fighting this issue the last couple nights. I wrote earlier about how Rack::PostBodyContentTypeParser can automagically turn a posted JSON object into a Rack / Sinatra params hash. So, I wrote some tests to make sure this was the case and moved on. Well, it turns out in real life things weren’t working and I couldn’t figure out why. Everything looked cool, but the hash wasn’t getting set when I did an AJAX call in the browser – everything was empty. I looked at everything, from the server, to the JS library, to the browser, to setting different content types in prototype.js etc… UGH!
The short of it is that Rack::PostBodyContentTypeParser requires exactly application/json in order to automagically turn the posted JSON object into Rack params and prototype.js (and jquery.js were adding an encoding type of charset=UTF-8 so the entire header entry was coming across as this CONTENT_TYPE: application/json; charset=UTF-8. So, as a fix, I’m just including the Rack::PostBodyContentTypeParser in the Sinatra application with one small change. Here’s the code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| module Rack
# A Rack middleware for parsing POST/PUT body data when Content-Type is
# not one of the standard supported types, like <tt>application/json</tt>.
#
# TODO: Find a better name.
#
class PostBodyContentTypeParser
# Constants
#
CONTENT_TYPE = 'CONTENT_TYPE'.freeze
POST_BODY = 'rack.input'.freeze
FORM_INPUT = 'rack.request.form_input'.freeze
FORM_HASH = 'rack.request.form_hash'.freeze
# Supported Content-Types
#
################## turned into regex so it matches type with encoding data...
#APPLICATION_JSON = 'application/json'.freeze
APPLICATION_JSON = /^application\/json/.freeze
def initialize(app)
@app = app
end
def call(env)
case env[CONTENT_TYPE]
when APPLICATION_JSON
env.update(FORM_HASH => JSON.parse(env[POST_BODY].read), FORM_INPUT => env[POST_BODY])
end
@app.call(env)
end
end
end |
I tested that this worked by writing the following:
1
2
3
4
5
6
7
8
9
10
| def test_post_as_json_converts_to_params
# sanity check that post with normal params works...
post '/test_params_as_json', :param1=>"param one"
assert_equal last_response.body,"params[:param1]=param one"
post '/test_params_as_json', {:param1=>"param one"}.to_json, "CONTENT_TYPE"=>"application/json"
assert_equal last_response.body,"params[:param1]=param one"
# this is the problem, adding a charset to the content type seems to breaks rack-contrib/post_body_content_type_parser.rb
post '/test_params_as_json', {:param1=>"param one"}.to_json, "CONTENT_TYPE"=>"application/json; charset=UTF-8"
assert_equal last_response.body,"params[:param1]=param one"
end |
Posted: April 4th, 2010 | Author: jay | Filed under: Code | Tags: charset, json, params, PostBodyContentTypeParser, prototype.js, rack, regex, sinatra, test | 4 Comments »
This could undoubtedly be more elegant, but it’s late and I want it to work now. May take another stab at it later…
TODO: limit the content types and only allow rendering if they are ok.
Setting up a before filter:
1
2
3
4
5
6
7
| before do
# remove and grab the file extension
request.path_info.sub! %r{\.([^\./]+)$}, ''
@format=$1 || 'html'
@charset=mime_type($1) || 'text/html'
content_type @charset, :charset => 'utf-8'
end |
and using a case statement:
1
2
3
4
5
6
7
8
9
10
11
| get "/home" do
case @format
when 'html'
@stylesheet='home.css'
haml :home, :layout=>:layout_simple
when 'js'
"{'js':true}"
else
pass
end
end |
Posted: April 1st, 2010 | Author: jay | Filed under: Code | Tags: before filter, file extension, format, mime type, sinatra | No Comments »