Permalink
Browse files

Converting blog posts into proper markdown.

  • Loading branch information...
ndrwhr-inkling committed Mar 12, 2014
1 parent 8dd6ae3 commit 5f0ff4bc15259281a2e13dd0709c11da21116aea
@@ -1,7 +1,4 @@
---
layout: post
title: Implementing Fractals
---
# Implementing Fractals
This experiment is something I had been thinking about for quite some time, but it was only recently that I decided to finally dive in and try implementing it. One the the biggest things encountered with this was trying to make the fractals responsive but still detailed.
@@ -13,8 +10,8 @@ As a quick example we can look at a simplified version of the Pythagoras tree. S
The last thing that I wanted to talk about was the Sierpinski Carpet. This is the only fractal here that is not drawn recursively. This is simply because the problem size grows very rapidly and the recursion would begin to bog things down. Instead everything (the spacing between the squares, the size of the squares etc) is calculated ahead of time, so that when it comes time to draw it is just a matter using a couple really simple loops.
h2. Further Reading:
### Further Reading:
If you're interested in reading some more about fractals. You can find a giant list here:
<a href='http://en.wikipedia.org/wiki/List_of_fractals_by_Hausdorff_dimension'>List of fractals by Hausdorff dimension (wikipedia)</a>
* [List of fractals by Hausdorff dimension (wikipedia)](http://en.wikipedia.org/wiki/List_of_fractals_by_Hausdorff_dimension)
@@ -1,13 +1,10 @@
---
layout: post
title: The Sudoku Solver
---
# The Sudoku Solver
After a bad run of making mistakes while marking up sudokus I thought I would try my hand at creating something to do the marking up for me. But as it turns out, I ended up writing something that would not only mark up the puzzles, but would more often than not entirely solve them.
h2. Which strategies does the solver use?
### Which strategies does the solver use?
I like my sudokus to be tricky, but not impossible. This means I don't believe you should ever have to guess a number to solve a sudoku. I also don't like all of the exotic named strategies that only work once in a million puzzles (jellyfish, swordfish, &amp;c.). That in mind, I wrote this program to use only the strategies that I would use to solve a puzzle:
I like my sudokus to be tricky, but not impossible. This means I don't believe you should ever have to guess a number to solve a sudoku. I also don't like all of the exotic named strategies that only work once in a million puzzles (jellyfish, swordfish, etc.). That in mind, I wrote this program to use only the strategies that I would use to solve a puzzle:
* Row, Column or Block Singles
* Naked Pairs
@@ -18,20 +15,22 @@ I like my sudokus to be tricky, but not impossible. This means I don't believe y
As I said before, I have absolutely no intention of implementing the silly named strategies.
h2. Hasn't this been done before?
### Hasn't this been done before?
Oh definitely! Everyone and their dog appears to have written one (a quick google search will reveal this). What I feel like other solvers don't provide is an easy to use interface. So even though other solvers may be more powerful, mine is at least easy to use.
h2. Updates:
### Updates:
* Pretty much rewrote the entire application:
** Switched from jquery to mootools.
** Now uses sets instead of strings to represent candidates.
** Consolidated state information.
** Improved efficiency across the board by throttling the amount of looping for most strategies.
** Fixed the horrible bugginess when demoing.
* Switched from jquery to mootools.
* Now uses sets instead of strings to represent candidates.
* Consolidated state information.
* Improved efficiency across the board by throttling the amount of looping for most strategies.
* Fixed the horrible bugginess when demoing.
* Added hidden pairs/triples strategies.
* Slight (in looks) interface change.
<div style='width: 640px; margin: 0 auto'><object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/9cHRJ3smwrU&amp;hl=en_US&amp;fs=1?rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/9cHRJ3smwrU&amp;hl=en_US&amp;fs=1?rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object></div>
Watch me coding it here:
* http://www.youtube.com/watch?v=9cHRJ3smwrU
@@ -1,9 +1,6 @@
---
layout: post
title: The State of Things
---
# The State of Things
In re-implementing my website I had several moments of, "My god, this code is awful!" or "I used to be proud of this?!", and quickly came to the conclusion that I should either:
In re-implementing my website I had several moments of, "My god, this code is awful!" or "I used to be proud of this?!", and quickly came to the conclusion that I should either:
* rewrite the program from scratch or...
* completely remove it and forget it ever happened.
@@ -1,18 +1,15 @@
---
layout: post
title: Look Ma', No Rails!
---
# Look Ma', No Rails!
I used to be in love with Rails. Coming from PHP, Rails made it so incredibly easy to layout, build and eventually extend websites. But there were also lots of things that made me really uneasy about Rails. Things like:
* Newer versions breaking my website when my host updated their servers (I eventually froze my site so that Rails wouldn't upgrade).
* Newer versions breaking my website when my host updated their servers (I eventually froze my site so that Rails wouldn't upgrade).
* The fact that I had to depend on my host for Rails support (I know could always buy a slice somewhere, but I really hate server configuration).
* The overall complexity and weight of Rails.
It wasn't until I came to work at "Inkling":http://www.inkling.com that a coworker, "Scott Kyle":http://appden.com, introduced me to Jekyll.
It wasn't until I came to work at [Inkling](http://www.inkling.com) that a coworker, [Scott Kyle](http://appden.com), introduced me to Jekyll.
Jekyll, for those who don't know, is a static site generator. Using a simple yaml front-matter (and tiny configuration files), Jekyll can infer the structure of your website and generate static html pages that can be served from nearly any server. In other words, it's awesome.
I feel a million times more free with Jekyll than I ever did with Rails...
Read more "here":http://www.jekyllrb.com.
Read more [here](http://www.jekyllrb.com).
@@ -1,30 +1,26 @@
---
layout: post
title: How I Learned to Walk
---
# How I Learned to Walk
Over the last couple weeks in my spare time, I decided to seriously mess around with CSS3. In particular webkit animations and transformations.
<object width="650" height="400"><param name="movie" value="http://www.youtube.com/v/gQDbxpSsSxs?fs=1&amp;hl=en_US&amp;rel=0&amp;hd=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/gQDbxpSsSxs?fs=1&amp;hl=en_US&amp;rel=0&amp;hd=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="650" height="400"></embed></object>
<p class='to-experiment'><a href="/experiments/walking">Go to the experiment!</a></p>
[See the experiment here](http://andrew-hoyer.com/experiments/walking/).
h2. Idea(s) and Inspiration:
### Idea(s) and Inspiration:
The walking experiment came from the need to work on something other than javascript for a while. Initially I thought I would do some kind of hybrid experiment mixing css animations and very minimal javascript, but eventually settled on using only CSS3 and html.
I threw around ideas of doing some kind of chaotic pendulum, or maybe a cleaner implementation of the robotic arm. The idea of doing the arm again, reminded me of the CSS3 AT-AT I saw a while ago. I remembered the first time I saw it, thinking, "This is incredible", before realizing just how limited the animation was. I thought maybe I could take it further and create something a little more extreme.
h2. Structure:
### Structure:
When I first started working on the walking man, I didn’t really know where it was going to go so I ended up going through several iterations of markup for the actual skeleton. But in each iteration the css and overall structure of the man got better and better, so I think it worked out for the best.
The key idea behind all of this is the fact that a css transformation applied to an element also applies to all of its children. Without this, I would have had to use all kinds of math to figure out how to make the joints match up. Instead all that work is done for me, all I had to do was animate each limb independently.
Ultimately, I landed more or less on the structure below:
{% highlight html %}
```html
<div class="torso">
<div class="left bicep">
@@ -52,16 +48,16 @@ Ultimately, I landed more or less on the structure below:
</div> <!-- right leg -->
</div> <!-- torso -->
{% endhighlight %}
```
As you can see from the html above, I would need to use z-indexes to push the left arm as well as the legs behind the torso, as well as move the shins and forearms behind the thighs and biceps, respectively. Z-Indexes turned out to be my biggest source of grief, and almost pushed me to aborting this experiment all together. First off, I'll completely admit that I had only a vague understanding of stacking contexts when I first set out.
As you can see from the html above, I would need to use z-indexes to push the left arm as well as the legs behind the torso, as well as move the shins and forearms behind the thighs and biceps, respectively. Z-Indexes turned out to be my biggest source of grief, and almost pushed me to aborting this experiment all together. First off, I'll completely admit that I had only a vague understanding of stacking contexts when I first set out.
With my limited knowledge, I thought I could just give negative z-indexes to things I wanted floated behind... But as it turns out, you can only push a child element behind its parent if its parent does not have a z-index set. This means if I set the z-index of the left bicep to -1, I would never be able to move the left forearm behind the left bicep. The other problem that I found was that the moment I started animating anything, webkit would basically destroy the stacking contexts.
In the end, I found that if I added a little more markup, not only would it make more semantic sense, but also solve all of the above problems:
{% highlight html %}
<div class='me'>
```html
<div class="me">
<div class="torso">
<div class="left leg">
@@ -95,14 +91,14 @@ In the end, I found that if I added a little more markup, not only would it make
<div class="right forearm"></div>
</div>
</div> <!-- right arm -->
</div> <!-- torso -->
</div> <!-- me -->
{% endhighlight %}
```
Note that I only really changed two things. First I wrapped each limb in another div, this was the main solution. I also moved the definition of the arms to be below the legs. I had originally done this in order to make sure that the arms would always display above the legs thus saving me a little bit of css (but not really).
h2. Animating:
### Animating:
One goal of this experiment was to create something that would work extremely well on iPhones, iPads and iPods. To do this, all I needed to do was make sure I animated only a certain subset of properties. The key one being -webkit-transform (for rotation and translation), as it has been optimized in mobile safari.
@@ -116,14 +112,13 @@ Unfortunately, mobile safari apparently is not as well equipped as its desktop s
So after all that work to get things working so beautifully as a single animation, I reverted back to doing separate animations for the left and right sides. Although this time, to maintain my sanity, I decided to use only 0%, 25%, 50%, 75% and 100% as my keyframes. This made things nice and easy to offset.
h2. Little Tidbit:
### Little Tidbit:
Just to kind of show off the fact that everything in the experiment is a div, I decided at one point that I would like to add a little feature to show this off. The easy solution would be to add a little bit of javascript that would add a border or background color to every div in the "canvas". But I thought this would be cheating a little on my goal of keeping the experiment free of javascript. The solution to this actually came from my coworker Scott Kyle (www.appden.com).
At the bottom of the page, you can see that there are two links to show and hide the element borders. One simply has an href of "#canvas" and the other "#", respectively. Then leveraging the target pseudo selector, I could just add a few more lines of css. This is what it looks like:
{% highlight html %}
```html
<style type="text/css" media="screen">
#canvas:target div:not(.overlay) {
@@ -136,23 +131,20 @@ At the bottom of the page, you can see that there are two links to show and hide
</style>
<p style='text-align: center'>
<a href='#canvas'>Show</a> /
<a href="#">Hide</a>
<p style="text-align: center">
<a href="#canvas">Show</a> /
<a href="#">Hide</a>
Element Borders.
</p>
```
{% endhighlight %}
h2. Final Thoughts:
### Final Thoughts:
Thats more or less it. In the end its quite amazing to see something with so much motion in a browser, yet not having any code. I also find it to be pretty incredible that it works just as well on my iPhone 3G as on my iPad or laptop.
In case you're interested, here is the complete source of the experiment:
{% highlight html %}
```html
<style type="text/css" media="screen">
#canvas {
height: 600px;
@@ -430,24 +422,24 @@ In case you're interested, here is the complete source of the experiment:
background-image: url({{ page.resource_url }}clouds/3.png);
-webkit-animation-duration: 140s;
}
.cloud-7, .cloud-8 {
top: 100px;
width: 94px; height: 81px;
background-image: url({{ page.resource_url }}clouds/4.png);
-webkit-animation-duration: 90s;
}
.cloud-1 { left: 0px; }
.cloud-2 { left: 1200px; }
.cloud-3 { left: 250px; }
.cloud-4 { left: 1450px; }
.cloud-5 { left: 500px; }
.cloud-6 { left: 1700px; }
.cloud-7 { left: 950px; }
.cloud-8 { left: 2150px; }
@@ -501,7 +493,7 @@ In case you're interested, here is the complete source of the experiment:
0% { -webkit-transform: translateX(0px); }
100% { -webkit-transform: translateX(-1200px); }
}
@-webkit-keyframes prop-2000 {
0% { -webkit-transform: translateX(0px); }
100% { -webkit-transform: translateX(-2000px); }
@@ -577,9 +569,7 @@ In case you're interested, here is the complete source of the experiment:
</div> <!-- canvas -->
<p style='text-align: center'><a href='#canvas'>Show</a> / <a href="#">Hide</a> Element Borders.</p>
{% endhighlight %}
<p style="text-align: center"><a href="#canvas">Show</a> / <a href="#">Hide</a> Element Borders.</p>
<p class='to-experiment'><a href="/experiments/walking">Go to the experiment!</a></p>
```
@@ -1,22 +1,19 @@
---
layout: post
title: Function.prototype.bind
---
# Function.prototype.bind
In my day job I spend all of my time rolling around in the warmth of Mootools. But lately I've been feeling kinda weird. With all of the things Mootools provides, I began feeling sort of disconnected from the vanilla javascript community. The line between what was native js and what Mootools provided was beginning to blur.
So I decided that for my next side project (which should be up in a week or two), I would take a step back and write a full experiment using only vanilla js. No libraries. I know that some people think this is a silly decision, as Mootools not only provides handy extensions to natives, but also patches over the differences between the various states of browsers. I fully recognize and agree with that fact, but I was just curious what could be done with the latest version of the browsers.
One of my favorite parts of Mootools, is that it has taught me to love passing functions around all over the place, but as we all know maintaining @this@ can be a tricky task. A classic example and solution to @this@ problem (har har), would look like:
One of my favorite parts of Mootools, is that it has taught me to love passing functions around all over the place, but as we all know maintaining `this` can be a tricky task. A classic example and solution to `this` problem (har har), would look like:
{% highlight js %}
```js
var Mouse = function(){
// assign this to that.
var that = this;
this.position = [0, 0];
document.addEventListener('mousemove', function(event){
that.move(event);
});
@@ -33,13 +30,13 @@ Mouse.prototype.log = function(){
new Mouse();
{% endhighlight %}
```
What I've done here, is just assigned @this@, which is a reference to the mouse class, to a variable and then referenced it inside of an anonymous function which will be called whenever the mouse moves. Although this works, I personally find it looks quite gross. Thankfully there is a better solution.
What I've done here, is just assigned `this`, which is a reference to the mouse class, to a variable and then referenced it inside of an anonymous function which will be called whenever the mouse moves. Although this works, I personally find it looks quite gross. Thankfully there is a better solution.
Poking around the Function documentation on MDC, I recently discovered that JavaScript 1.8.5 implements a "new bind method":https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind. This methods takes the current function, wraps it up in a closure and returns a new function that will maintain the passed in binding. Basically, it does something like this:
Poking around the Function documentation on MDC, I recently discovered that JavaScript 1.8.5 implements a [new bind method](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind.) This methods takes the current function, wraps it up in a closure and returns a new function that will maintain the passed in binding. Basically, it does something like this:
{% highlight js %}
```js
var bind = function(fn, binding){
return function(){
@@ -56,11 +53,11 @@ var wrappedUp = bind(myFunction, { message: 'hello world' });
myFunction(); // logs 'undefined'
wrappedUp(); // logs 'hello world'
{% endhighlight %}
```
This to me is a godsend, as it was one of my most missed 'features' provided my Mootools. The Mouse class can now be simplified a little:
{% highlight js %}
```js
var Mouse = function(){
// Look! no that = this!
@@ -79,10 +76,10 @@ Mouse.prototype.log = function(){
new Mouse();
{% endhighlight %}
```
Unfortunately though, the bind method doesn't seem to be supported yet in the Webkit Nightlies or Safari. But if you do want to check it out, just open up the most recent version of Chrome or Firefox 4 and start natively binding your functions!
All in all, I'm quite happy with how working with native JS has been going, sure I miss some of the nicer array methods from Mootools (invoke, erase etc.), but seeing just how many of them (most of the iterators) have made their way in to browser implementations makes me incredibly happy.
For browsers that don't support bind natively, be sure to try out Mootools or at least steal "their implementation":https://github.com/mootools/mootools-core/blob/master/Source/Types/Function.js (but show them some love of course).
For browsers that don't support bind natively, be sure to try out Mootools or at least steal [their implementation](https://github.com/mootools/mootools-core/blob/master/Source/Types/Function.js) (but show them some love of course).
Oops, something went wrong.

0 comments on commit 5f0ff4b

Please sign in to comment.