Skip to content

Innate Creativity and Eureka Moments

Problem solving is a very specific process. It’s what your mind goes through when you have a problem with no apparent solution. I’m talking about those kinds of problems that you spin your wheels on for hours on end. The kind where despite all that wasted time, the solution comes to you in the least likely places and times; when you’re asleep, when you’re in the shower, etc.

Suddenly you have that Eureka Moment. You think to yourself “it’s so obvious now” and wonder why it took so long to figure it out. The reason why, of course, is you were thinking too much about it. I’ll put it plainly; your conscious mind is an incredibly dumb and narrow minded creature. Sure, it can figure out mathematics and science and any other logical topic, but outside of that it gets stumped. That’s why you waste hours on such problems.

What really solves problems is your subconscious mind and believe me it’s really good at it. As soon as your let go of the issue your subconscious cracks it’s knuckles and says “let me show you how we do this.”

I’ve been finding more and more recently that when I start to get stuck on a really difficult problem it’s just easier to forget about it and move on to something else for a bit. I’m even finding that you can really develop subconscious problem solving as a skill. The skill is in being able to let go of an issue in spite of the immediacy of the it. Stressful problems are the hardest to solve and the hardest to give up, but there’s also what the subconscious excels at.

So the next time you’re in a crunch and you can’t figure something out, just let go of it.

Posted in Uncategorized.

Tagged with , , , , .

No comments

By Rhysyngsun – February 28, 2010

Fun with Groovy Closures

I’ve been working with some of Groovy’s more powerful concepts lately and thought I would share some of the stuff I’ve discovered that is not readily apparent in the documentation. I myself took Groovy closures for granted for a while but once you really start to understand how powerful and flexible they are you can really start to code what would otherwise be mind-boggling concepts in vanilla Java.

Take the following example code for instance:

All three examples illustrate the same concept: using a Groovy closure to call a method on and arbitrary string instance. You could of course be doing much more in that closure, but for purposes of illustration i’ll keep it simple.

What we’re doing in examples 1 and 2 is changing the scope that the closure gets evaluated under. Normally, a delegate will resolve this to the scope that it was defined in. By setting the resolveStrategy and delegate, we tell it to look for a delegate first and resolve this to the delegate object. The delegate can be any Groovy/Java object. In doing so, when we invoke the closure, the split() method gets called on the splitMe object we assigned to delegate.

Example #2 is simply a Groovy convenience method for the same. You can either pass the closure as an argument or define it inline.

Example #3 probably looks familiar if you’ve ever used Groovy’s extensions to Object. By using Closure.call(), we can pass in an arbitrary number of arguments. Since we’re only passing in one, we gain the convenience of the untyped “it” property that you normally expect to be passed to a closure.

Closure.call() is an extremely powerful method that you can use to define your own Groovy iterator methods!

Posted in Java.

No comments

By Rhysyngsun – August 19, 2009

Frameworks are a Terrible Thing

This is a rant that has been building in me for a while. This is probably going to be a bit raw as a result.

I’ve seen a lot of talk about MVC in Flex/ActionScript circles over the last year or so and wish I had voiced my opinion a little earlier, so I apologize if the timing of this seems misplaced.

I’ll start with the particular impetus for writing this article (from an article today on InsideRIA):

The biggest problem facing Cairngorm is the apparent lack of documentation. It can be argued that Cairngorm is a highly flexible architecture that is poorly represented by a few meagre examples.

Counter argument here would be that the biggest problem for a framework like Cairngorm is not the lack of documentation; it’s the fact that the documentation that exists advocates design patterns and code behaviors that would make a seasoned developer cry. Frameworks like this cause too many developers to stop thinking about their code design.

There are situations where a pattern such as MVC should be followed, it helps your code flow and everything runs smoother, but I get the sense that there are far fewer developers who question why they are doing MVC than there should be.

How many question “Is this a good use case for MVC?” or are you just coding that way cause thats the only way to cram it into your classes? I see too many developers get stuck in cookie-cutter solutions: singletons, reinvented event management, 100s of files of boilerplate code. What became of good software architecture?

My attitude these days is that I’ll use whatever is good for the job and stays the hell out of my way when I do it and doesn’t make me fight the framework when I try to implement a modified architecture. There is one particular framework that does this for me for now, until something better comes along.

I’d love to hear others opinions on this as well.

Posted in ActionScript, Development, Flex, Programming.

9 comments

By Rhysyngsun – July 13, 2009

HTTP and the Stagnation of the Web

If you’ve read some of my previous posts, me and the current state of web technology have shared a love-hate relationship, more so on the latter side of things recently. Frankly I think the web has reached the pinacle of it’s current incarnation. Sure, there are lots of companies out there working hard, but for all the effort, little progress has been made.

I’ve come to believe that the main culprit of this is the HTTP protocol. It’s inefficient and encourages uses of technologies such as HTML, XML, and JSON. These technologies had their time, but I would think by now that time should have passed.

To give a comparison, the web is in the same technology state as the automotive industry. Over the years cars have changed in appearance to fit the times and consumer appeal, and thus have websites changed. Sure some new technological offshoots have occured to support these changes, but these changes have been at best iterations.

Now we’re here in the year 2009 and the automotive industry is facing consumer pressure to find alternatives to expensive fuel consumption on diminishing fossil fuels. So the automotive industry has begun to respond with more fuel efficient vehicles, but that only delays the fact that we won’t be able to run on fossil fuels forever.

Similarly, the web continues to run on HTTP, all the while seemingly not realizing that this protocol and behavior is simply not maintainable if we ever want the web to move on.

Personally, I think binary protocols are the future of the web. Now I know the majority of web developers would cringe at that, saying they like plain text protocols, but really, why does the data need to be transfered in plain text as long as a binary transfer can be transcribed to a human readable format on the client end?

The problem lies in the transition and that problem is threefold: browser compatibility, site compatibility, and search indexing. Current browsers have a hard enough time with HTML and CSS, so a new protocol would need extremely strict compliance standards. Everyone is aware of these issues but consumers really don’t push back like they should.

Site compatibility covers the issues of existing sites that this new system would need to be backwards compatible with. Sites like this would probably be phased out gradually (when was the last time you saw a ‘96 era site that was popular? )

Finally, every search engine out there relies on theese plain text protocols for indexing, so some considerations would need to be made for them. Take for example the Flash format, which was not originally designed to be indexable, and now there are efforts to go back and make it indexable without majorly rearchitecting the format. It’s proven to be difficult so far.

There’s only so much HTTP can do, and while it does have it’s uses, there are better routes to go in the future.

Posted in Programming, Technology, Web Development.

4 comments

By Rhysyngsun – January 1, 2009

My Future with Merb, Rails 3, and Ruby

So after my initial negative reaction to the announcement of the merger, I’m slightly less worried about it, but still not at all happy about it. I have no doubt that this initial release of Rails 3 will be a big win for Rails programmers, but I’m very worried about Rails slipping back into the depths of bloatware. If that happens, all this merger will have accomplished is to get rid of or (best case scenario) demote the popularity of Merb or any subsequent forks.

It’s absolutely great that the Rails team had finally realized that opinionated software isn’t a win-win situation. But now there won’t be any major competitor for Rails. By that I mean, Rails will once again be the “best” option especially as there won’t be competing frameworks that are as flexible as Rails will be. I have a very bad feeling that lack of competition will lead to another stagnation of the framework. Just look at what Merb has done for Rails, made it look at itself and realized it needed to change.

At this point my options are few: get out of Ruby and find a web framework in another language, fork Merb, roll my own, or use Rails 3.

Option #1: Leave Ruby for a Framework in Another Language

I’m not at all favoring option 1 since I absolutely love Ruby and no matter how disappointed I am in these recent events, I won’t hold it against the language.

Option #2: Fork Merb

Definitely possible, although it’s not like I could maintain an entire framework like Merb as a lone wolf. Also a lack of community is a little disheartening.

Option #3: Roll My Own

Obviously this would be a tremendous effort of time and energy, although it could be a massive learning experience. Not necessarily the best option if I actually want to accomplish web projects in the next year.

Option #4: Rails 3

I would have to say that at the very least, in order for this to happen it would have to be proven to me that in at least 90% of cases that Rails 3 will at least as good as Merb 1.x was. That means performance, volume of code, quality of public APIs, lightweight, flexibility, etc. Suffice it to say, Rails 3 will have a lot to prove to me before I could condone using it.

Conclusion

My conclusion is that for now I’m going to focus on pure Ruby / Merb projects running with a forked version of the 1.x line. I probably won’t be altering any of the forked code for now, but using it as a stable copy. When Rails 3 comes out I’ll probably give it a try, but it’s going to go through quite the gauntlet for me to accept it as a viable production technology.

Posted in Merb, Programming, Ruby.

No comments

By Rhysyngsun – December 31, 2008