Entries Tagged 'Uncategorized' ↓

Just a tidbit of regex I am using on a current project.

Ever needed to match a phone number with a piece of regex?

/([0,1]{1})?([-| |.]+)?(?([0-9]{1,3}))?([-| |.]+)??([0-9]{3})([-| |.]?)+([0-9]{4})/

What does it do? It matches a phone number from (520) 444-4444, 429-333-3333 and a few other combinations. Check it out, try it!

If you can think of other combinations, let me know, I’ll update the regex
UPDATE
Just to let ya know… Here is the rspec for the phone number regex. I’m sure there are more.

Cool!

coming up…

• Plugins (coming soon!)
• A piece of wisdom about RMagick/ImageMagick (you don’t wanna miss this one)
• A comment about being a freelancer
• and more!

Since Wordpress is pretty dumb, I’ve attached it as a document. You can fetch it here:

UPDATED

I think I’ll rewrite this blog in Sinatra.

The green bar

There is something very satisfying about seeing the green bar. If you are not sure what I am talking about, check out TDD, Textmate, and most importantly ZenTest (okay, this is also a big help).

So who the heck cares about Test Driven Development?

You know you heard it from your Java teacher and hated using it in JUnit. But, there is hope and rationale for using it.

Okay, yeah, this is another post about testing, but it’s super important and super cool. I plan on updating this post in the future and possibly turning it into a page, but I’m going to list out my practices in testing and hopefully it’ll help someone else. I’ll also explain some schtuff and we’ll work it out together, w00t.

Okay, here goes:

When/what to test
Test your own code. We all know that the rails framework is well-tested, so why test their code?

I write tests on all my models that require my model to behave like I want it too. I am guilty of doing something like this though:

	def test_title_should_have_limit_on_title
		post = Post.new
		post.title = "title is no longer than it should be"
		assert post.save
	end

(Okay, so that is a contrived example). But, what exactly is that testing? It’s testing the rails framework! We don’t need that. The test could be written to test the constraints of the application. For this instance, I’d write it closer to the actual application specs to ensure that it didn’t break.

Functional test
Holy crap, I hate functional tests, but they are so useful. God, someone get me a napkin, some yogurt just splurted out my nose, that’s how angry I am about my love/hate relationship with the buggers! The functional test can show you exactly what you are doing with a controller and when. For instance, when I have a complicated controller situation, rather than press buttons in the browser, I just watch my little red bars and enjoy the sight of all the work I have to finish.

For instance, I have several places where I use abstract controllers in my applications. Those are perfect to test! What happens if a user is logged in and goes to a place where they have to be logged out, or visa versa?

Write a test!

	def test_register_a_user
	    get :register
	    assert_response :success
	    post :register, :user => {:email => "ted@teddy.com", :password => "testy", :password_confirmation => "test", :username => "teddy"}
	    assert_response :success
	end

How wonderful!

Now, I really should be getting back to work. I’ll shuffle off the work-papers soon and write some more of this post, but… for the time being, enjoy the shortness. You can read it on your iPod, probably and not even have to scroll down. Well, maybe once.

I have made it out of school for the semester (thank god, one more to go) and have been trudging away at some work schtuff ahead of me. Finally, after getting some silly things resolved, the product is coming together! (Can I get a what?… what?)

But more importantly, (railsconf ‘07!).

For the next 4 days I will be in Oregon promptly followed by a stay in LA. OOOoooo It’s going to be fun!

Also, as I promised a friend of mine, for those of you looking for my quick-n-dirty ruby introduction, I’m working on it, slowly. Just have other things on my plate right now. I’ll try to get that out soon.

w000000000000()()()()()()

occupy.

Will be out of hibernation soon.

Read line #24

Don’t be evil

Menus should represent the items served at a location. If an item is on the menu, there is an expectation that it will be served.

Bread bowls apparently do not sell well.

People like pizza with toppings and not bread bowls with soup.

World Banking
Good for criminals

Internet
Who wants the internet to be devoid of fun? Not me, not anyone… including senators. Problems arise when the fun on the internet replaces the fun of homework.

Hours of fun.

For a project I am working on, I have had to research a rather antiquated, but still widely used (and not patented by unisys anymore) compression algorithm. It took me a rather long time to actually understand the algorithm and be able to effectively be able to use it.
So, for the future and if anyone is actually going to use the compression scheme again, hopefully this helps you out so you don’t have to wander through the ugly c code.

First, the compression algorithm.

The way LZW works is that it “looks ahead” in the string array to be coded and looks if it has been inserted into the local dictionary.

Meaning…
Let’s say that we have a string
string = “ababa”
Now, with that string, the module will go through each character and “look ahead” to see if it has been encountered before. So… first output would be the number for a, which in our case will be the number 97. That is saved in the dictionary. The second number will be 98 (b). Now, the dictionary will look into the next byte and see if it is in the dictionary. If it is not (like in our case) it will output the first byte to the result. If it is, then it will set the code as the last output byte (the pair of bytes in the dictionary).

See below for the algorithm.

data = "ababa"
codes = []
## encode

	dict = {}
	prev = nil
	newcode = 258
	data.each_byte do |byte|
	  if prev.nil?
	    prev = byte
	    next
	  end
	  pair = [prev, byte]
	  if oldcode = dict[pair]
	    prev = oldcode
	  else
	    codes << prev
	    dict[pair] = newcode
	    prev = byte
	    newcode += 1
	  end
	end
	if !prev.nil?
	  codes << prev
	end
      

*Decoding*
This is a little more difficult. In fact, I’m still trying to understand this, but here goes.

First, you want to go through the coded array (In our case, from the encoded string “ababa”, the array would be [97, 98, 258, 97]) and see if we have a previous byte. If we do, then we are going to put whatever the code is and set it as the last byte read. If we don’t then we are going to look through the code and set the coded array into the bytes until we have no more outside the literal 8-bit values.

Meaning…, we are going through the dictionary until we have a code that is a literal.

We takes the bytes are reverse them as they will be the outputted data.

We continue down this path until all the codes are taken care of!

## decode                   

	dict = {}
	prev = nil
	newcode = 258
	codes.each do |oldcode|
	  if prev.nil?
	    puts oldcode
	    prev = oldcode
	    next
	  end
	  bytes = []
	  code = oldcode
	  while 256 <= code
	    code, byte = dict[code]
	    bytes << byte
	  end
	  puts code
	  bytes.reverse!
	  bytes.each do |byte|
	    puts byte
	  end
	  if oldcode == newcode
	    puts oldcode
	  end
	  dict[newcode] = [prev, code]
	  prev = oldcode
	  newcode += 1
	end

I may post the module when I am done with it in a few

When I speak up…

and I am there, I get yelled at for causing a disruption and told I can’t “speak” unless I am not
when I am not, I get told I am complaining and that I should only “talk” when I am there.

So much for transparency

Hm. So, today’s paper (I’m just looking online) is actually not nearly as hideous as yesterday’s. I am only looking at the front page, so it’s just front page stuff today.

1) The teaser, finally something comes of it. Move the fu*king page numbers up away from the line, push them down a font size and for the LOVE of god stop capitalizing EVERYTHING. But other than that, they look pretty good.

The photo provides a nice feel to the page. Without it, it would be pretty shitty. I would have shot from another angle, but that’s a personal thing. It looks good to me.

There are no headlinees that stick out to me today. It seems like there are two big stories here that could have used larger treatment. The lead story and the NPR story are both interesting to the reader and I’m left just kinda wandering around the page. Sad.

The blue in the Wet And Wild box is a bit much. The photo itself stands alone, why clutter it up?

Other than the things mentioned and a few things I left out ’cause they are tiny, today’s front page design is not too bad. I’m still disgusted at the teasers, but they are getting better than the first several concepts.

- antagonist

It seems as close as I get to something new, I get so far away.

I think it smells good outside when it rains. It’s also good looking too, especially when someone falls down or is wearing all white.

Teddy bears are for the weak, teddy chain-saws are for the strong

Anyone own a camera around here? Good. I’m typing in my undies

The lighter it gets outside, the louder I turn up my alarm clocks

Fish babies are exciting. Sadly, you can’t pet them, but you can enjoy them. It’s also sad knowing their parents will eat them for dinner… or lunch. I don’t think fish know about brunch (that’s a human thing)

New York City is overrated. The subway is underrated.

Does the CEO of Ford know he’s an enemy of the White House or is he so far hidden behind his money he can’t?

Girls who wear shorts to work are not lawyers

Guys who wear ties to work are not fishermen