I haven't written here in a while. My plans for exploring new frameworks were either put on hold or accelerated by a change of leadership at my job. The new leader wants to enact a radical change of technologies, which I very much support. It looks like I'll be doing Ruby and Rails for the forseeable future, and while I'm fine with that, it's such a learning curve that I don't think I can spend time (at least any time soon) exploring the Scala-based frameworks I was interested in. Maybe I'll head there someday, but for now, I think I'll switch gears here and start using this venue to help further my reacquaintance with Ruby and my acquisition of the new Rails stuff. It's been years, and a lot has changed.
Ruby is good. It's far better than Java, and while I don't like it as much as Scala, it will do. It is flexible and supports some of the more functional style I'm interested in.
Javascript? Nothing's changed there. I'm still very interested in exploring the current state of the industry (as outlined very well in this page) concerning rich Javascript frameworks.
So, my plan is now to write a game using Rails and one or more of these Javascript frameworks or libraries. I still want a very separate client and server, which might involve only serving JSON or something similar.
One more thing: a framework I have recently been playing around with is Node.JS. I started writing a test application in Node and succeeded in downloading an xml file, converting it to JSON and serving it to a page. I put it on Heroku here. This is a very interesting and understandably controversial (anti-) framework: concise and powerful yet so different from the monoliths I'm used to. It gives you very little and expects little from you. It was interesting and I think I'll do more with it if I get a chance, but for now I'm leaning toward not using it for my app. I'll probably post more on Node at a later date.
Wednesday, December 19, 2012
Wednesday, September 5, 2012
Scala
I've been focusing a bit of my free time on Scala. It's possible to write procedural, Java-style code in Scala, but I've been trying to follow the recommendations and learn to program in a functional style.
I have been a fan of certain functional idioms for quite a while. For instance, given a collection of strings and the need to determine if all of its strings match a certain regex, the typical Java developer would probably do something like this:
It's ugly and verbose. I think a lot of the reason this is still idiomatic Java is the annoying fact that Java still doesn't have closures, since closures enable concise code like this Scala:
You can hack this kind of thing in Java with anonymous inner classes, but it's ugly and I feel it's often not worth the effort. Sometimes I mess around with Apache CollectionUtils' Predicates to approximate the same idiom, but it always feels gross. On the other hand, every time I give up and write a loop I feel dying a little inside. Scala is much more of a pleasure to use than Java because you can more often just say what you mean.
I like Scala's typing. I like that variables are statically typed, but I can declare a variable's type or leave it off and let the compiler figure it out.
I love being able to represent a function in concise inline notation. Even JavaScript, which is pretty good at letting you treat functions as first-class constructs, makes you say "function" when you declare one. In Scala you can just say "_.matches(regex)".
So, I've been practicing by doing some Project Euler problems in Scala. It's been a great learning experience, but wow it sure has highlighted just how different the typical functional programming style—with all its immutability and linked list manipulation—is from what I'm used to. It's a flashback to my LISP days in college, which isn't necessarily a good thing. (Spoiler: I never really liked LISP.)
Consider a program like this, which is a solution to Problem 7, and took me several minutes to parse:
Here's my attempt at an English version of the above:
The value ps is a Stream, which is basically a lazily-populated list of numbers. The first item in the stream is 2, and each successive number is provided by filtering out numbers from the integers (starting with 3) which fit a certain criterion...
The criterion that each number N must satisfy is that all items from the set of numbers in this same stream ps that are less than or equal to its square root are found to follow a certain property...
The property each such number must follow is that N not be evenly divisible by it.
Once the stream is established, that its 10000th member, and you have the 10000th prime number.
It's concise, that's for sure. And slick as hell. But is it readable? I don't know. I mean, I can read it now...if somewhat slowly. I'm used to having a lot more words and symbols per idea at my disposal. So was it just a learning curve I had to navigate, or is the language actually obtuse? I guess I'll see, because I'm going to use it to write my new app.
I have been a fan of certain functional idioms for quite a while. For instance, given a collection of strings and the need to determine if all of its strings match a certain regex, the typical Java developer would probably do something like this:
boolean allMatch = true;
for (String s : strings){
if (!s.matches(regex)){
allMatch = false;
break;
}
}
if (allMatch){
doSomething();
}
It's ugly and verbose. I think a lot of the reason this is still idiomatic Java is the annoying fact that Java still doesn't have closures, since closures enable concise code like this Scala:
if (strings.forall(_.matches(regex)))
doSomething()
You can hack this kind of thing in Java with anonymous inner classes, but it's ugly and I feel it's often not worth the effort. Sometimes I mess around with Apache CollectionUtils' Predicates to approximate the same idiom, but it always feels gross. On the other hand, every time I give up and write a loop I feel dying a little inside. Scala is much more of a pleasure to use than Java because you can more often just say what you mean.
I like Scala's typing. I like that variables are statically typed, but I can declare a variable's type or leave it off and let the compiler figure it out.
I love being able to represent a function in concise inline notation. Even JavaScript, which is pretty good at letting you treat functions as first-class constructs, makes you say "function" when you declare one. In Scala you can just say "_.matches(regex)".
So, I've been practicing by doing some Project Euler problems in Scala. It's been a great learning experience, but wow it sure has highlighted just how different the typical functional programming style—with all its immutability and linked list manipulation—is from what I'm used to. It's a flashback to my LISP days in college, which isn't necessarily a good thing. (Spoiler: I never really liked LISP.)
Consider a program like this, which is a solution to Problem 7, and took me several minutes to parse:
lazy val ps: Stream[Int] = 2 #:: Stream.from(3).filter(i => ps.takeWhile(j => j * j <= i).forall(i % _ > 0)) val r = ps(10000)
Here's my attempt at an English version of the above:
The value ps is a Stream, which is basically a lazily-populated list of numbers. The first item in the stream is 2, and each successive number is provided by filtering out numbers from the integers (starting with 3) which fit a certain criterion...
The criterion that each number N must satisfy is that all items from the set of numbers in this same stream ps that are less than or equal to its square root are found to follow a certain property...
The property each such number must follow is that N not be evenly divisible by it.
Once the stream is established, that its 10000th member, and you have the 10000th prime number.
It's concise, that's for sure. And slick as hell. But is it readable? I don't know. I mean, I can read it now...if somewhat slowly. I'm used to having a lot more words and symbols per idea at my disposal. So was it just a learning curve I had to navigate, or is the language actually obtuse? I guess I'll see, because I'm going to use it to write my new app.
Friday, August 17, 2012
Angular
Angular is another Javascript library I've been looking at. It's maintained by Google, which inspires confidence. Here's its premise:
It turns out what they do is take HTML by the horns and bend it to their will, adding attributes, basically extending it to be something more like the language it should be in this day and age. A lot of the focus seems to be on automatic data binding, much like what Knockout does.
I ran through their tutorial, and it's pretty impressive. I had no idea people were doing things like dependency injection in Javascript, within a browser. Or that such good, behavior-driven unit testing was possible in Javascript.
Basically, what you do is link to their script and put their attribute in your <html> tag. That sets Angular loose in your page, and once it works its magic you can do things like iterate over collections simply by adding a custom attribute to an <li> tag, or invoke some advanced, route-based templating and partial-page inclusion, and even interpolate expressions like {{"here is" + "my text"}} right into the page text. This is all stuff I'm used to doing with a server-side framework so it's familiar, but it's very compelling to see so much of it pushed to the client. That just makes sense when more and more of the application is happening in the browser.
The dependency injection comes into play in enabling mocks for testing (which runs in-browser, pretty cool) and injecting advanced data handlers that interact with the server (in their example, a RESTful component for effortless CRUD).
Good stuff. Chances are really high that I'll be using Angular for my app.
HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications. AngularJS lets you extend HTML vocabulary for your application. The resulting environment is extraordinarily expressive, readable, and quick to develop.
Other frameworks deal with HTML’s shortcomings by either abstracting away HTML, CSS, and/or JavaScript or by providing an imperative way for manipulating the DOM. Neither of these address the root problem that HTML was not designed for dynamic views.
AngularJS is a toolset for building the framework most suited to your application development. It is fully extensible and works well with other libraries. Every feature can be modified or replaced to suit your unique development workflow and feature needs.I definitely agree that HTML isn't an ideal tool for today's web, so I found this an interesting premise—though at first glance I wasn't really sure what it would look like to build a framework that doesn't "abstract away HTML, CSS and/or JavaScript".
It turns out what they do is take HTML by the horns and bend it to their will, adding attributes, basically extending it to be something more like the language it should be in this day and age. A lot of the focus seems to be on automatic data binding, much like what Knockout does.
I ran through their tutorial, and it's pretty impressive. I had no idea people were doing things like dependency injection in Javascript, within a browser. Or that such good, behavior-driven unit testing was possible in Javascript.
Basically, what you do is link to their script and put their attribute in your <html> tag. That sets Angular loose in your page, and once it works its magic you can do things like iterate over collections simply by adding a custom attribute to an <li> tag, or invoke some advanced, route-based templating and partial-page inclusion, and even interpolate expressions like {{"here is" + "my text"}} right into the page text. This is all stuff I'm used to doing with a server-side framework so it's familiar, but it's very compelling to see so much of it pushed to the client. That just makes sense when more and more of the application is happening in the browser.
The dependency injection comes into play in enabling mocks for testing (which runs in-browser, pretty cool) and injecting advanced data handlers that interact with the server (in their example, a RESTful component for effortless CRUD).
Good stuff. Chances are really high that I'll be using Angular for my app.
Friday, August 3, 2012
Knockout
Yesterday I spent a while running through the tutorials offered on the site for the Knockout Javascript library. Knockout's concept is what they call MVVM; I'd never really heard of that particular acronym, and while I initially thought it was a bit awkward, I do understand what they're driving at.
Knockout is purely client-side, so it remains open to work with whatever method you use to provide data from your server. It just wants JSON, which is fine because that's what I was planning on. But while it's a client library, it isn't trying to be a flashy effects library like Prototype or even a utility belt like JQuery. In fact, it seems to play nicely if you also want to use other libraries like that. It focuses on one concept and tries to do that well, which I like.
What Knockout concentrates on is the problem of keeping a UI in sync with data. I appreciate this, because I remember that a lot of time I've spent while writing Ajax-oriented apps has been centered around getting the newly-received server data into the right part of the page. Knockout makes it automatic. You have your model in the server, and when it comes over to the client it becomes the "view model". Then, instead of having to find the right
And how does the data gets from the server to the client? They seem to want to that leave to other libraries like JQuery.
Their homepage contains some really cool interactive tutorials that show off the functionality. Overall I was impressed, and I could see this library becoming part of the stack I use to build my app.
Knockout is purely client-side, so it remains open to work with whatever method you use to provide data from your server. It just wants JSON, which is fine because that's what I was planning on. But while it's a client library, it isn't trying to be a flashy effects library like Prototype or even a utility belt like JQuery. In fact, it seems to play nicely if you also want to use other libraries like that. It focuses on one concept and tries to do that well, which I like.
What Knockout concentrates on is the problem of keeping a UI in sync with data. I appreciate this, because I remember that a lot of time I've spent while writing Ajax-oriented apps has been centered around getting the newly-received server data into the right part of the page. Knockout makes it automatic. You have your model in the server, and when it comes over to the client it becomes the "view model". Then, instead of having to find the right
or whatever and put the data there, Knockout keeps it all synchronized for you. This works because of a few things you did at page startup: you set up an internal representation of the data (view model), marked some of those data as observable, and bound certain elements in your page as to portions of that data by using special html attributes.
And how does the data gets from the server to the client? They seem to want to that leave to other libraries like JQuery.
Their homepage contains some really cool interactive tutorials that show off the functionality. Overall I was impressed, and I could see this library becoming part of the stack I use to build my app.
Tuesday, July 31, 2012
I write a new app in a new stack
The time has seemingly come, as it occasionally does, for me to learn some new frameworks and/or languages and build a new app. I do this every once in a while when I'm completely bored by what I'm doing at work, and/or when I feel like I'm falling too far behind the cutting edge of the fast-paced world of web development. Basically, if I find myself thinking that I'm tired of programming, I slap myself and say, "Duh, you're not tired of programming; you're born to code! The problem is that you're stagnating. You need new horizons to explore." And it always turns out I'm right.
This time I think I want to write a game. That's nothing new; I usually write games for fun. But I need to learn something new. I've been doing a lot of JSF/Seam/ICEfaces at work, and I'm frankly quite sick of the stack (whether through some actual fault of the technologies, or simply from contempt bred of familiarity, I'm not sure). This stack is heavy and stateful, and tries to push all the client-side development out of Javascript and into server-side component libraries. The problems this approach can raise I am now very familiar with, so naturally my current grass-is-greener scenario involves a really stateless server and a lot more client development. Oh, and a lot of separation between server and client.
In fact, I'd love to completely divorce my client and server. Just to see if I can, I'd like to write one server component that is mostly centered around providing JSON services (maybe REST), using nothing but tests or possibly a command line as a client. Then I want to add in a web client, an Android client, and possibly even an iOS client and (if I get really crazy) a Windows and/or Mac desktop client. All these clients should be able to interact with the server the same way, meaning that you can play on the web against your friend who is playing on his Android.
This is ambitious, I know. But one advantage of this approach should be that if I lose steam halfway through that list of clients, I'll still have something to show for it.
I've started researching technologies. One I'm very interested in is Scala. I like many of the functional programming idioms, and I like the JDK, but I hate how slow Java the language is to add new features and keep itself relevant (still no closures?!). Developing in Java these days can be quite a chore when you've had a taste of the other languages that are available. Groovy was a possibility, but I've tried a large project in Ruby, and one thing it taught me is that I'm not a fan of dynamic typing. Scala is functional, concise, statically-typed, and gaining a lot of traction in the community. so Scala is a must for my server.
But the Scala web development world is confusing and new. The biggest players seem to be Lift and Play, but there are also smaller, purposefully lighter-weight projects called Scalatra and Unfiltered. I'll be researching these, taking notes here, and eventually choosing the one that seems to fit my needs.
I also like Javascript. For the web client, I want to use some of the amazing JS libraries that I'm aware of which have sprouted up in the years since I was really doing Javascript development. JQuery probably, and Angular or something like that. Batman, Cappuccino, etc. I know little about all of these, so a lot of research is in order. I don't yet understand what they all offer, so I'll be researching them and chronicling my findings here.
Some HTML5 research will probably be in order.
Android too. I'll have to take Android development back up at some point, and that will get some time here.
For now, that's all I'll promise. Stay tuned for the results!
This time I think I want to write a game. That's nothing new; I usually write games for fun. But I need to learn something new. I've been doing a lot of JSF/Seam/ICEfaces at work, and I'm frankly quite sick of the stack (whether through some actual fault of the technologies, or simply from contempt bred of familiarity, I'm not sure). This stack is heavy and stateful, and tries to push all the client-side development out of Javascript and into server-side component libraries. The problems this approach can raise I am now very familiar with, so naturally my current grass-is-greener scenario involves a really stateless server and a lot more client development. Oh, and a lot of separation between server and client.
In fact, I'd love to completely divorce my client and server. Just to see if I can, I'd like to write one server component that is mostly centered around providing JSON services (maybe REST), using nothing but tests or possibly a command line as a client. Then I want to add in a web client, an Android client, and possibly even an iOS client and (if I get really crazy) a Windows and/or Mac desktop client. All these clients should be able to interact with the server the same way, meaning that you can play on the web against your friend who is playing on his Android.
This is ambitious, I know. But one advantage of this approach should be that if I lose steam halfway through that list of clients, I'll still have something to show for it.
I've started researching technologies. One I'm very interested in is Scala. I like many of the functional programming idioms, and I like the JDK, but I hate how slow Java the language is to add new features and keep itself relevant (still no closures?!). Developing in Java these days can be quite a chore when you've had a taste of the other languages that are available. Groovy was a possibility, but I've tried a large project in Ruby, and one thing it taught me is that I'm not a fan of dynamic typing. Scala is functional, concise, statically-typed, and gaining a lot of traction in the community. so Scala is a must for my server.
But the Scala web development world is confusing and new. The biggest players seem to be Lift and Play, but there are also smaller, purposefully lighter-weight projects called Scalatra and Unfiltered. I'll be researching these, taking notes here, and eventually choosing the one that seems to fit my needs.
I also like Javascript. For the web client, I want to use some of the amazing JS libraries that I'm aware of which have sprouted up in the years since I was really doing Javascript development. JQuery probably, and Angular or something like that. Batman, Cappuccino, etc. I know little about all of these, so a lot of research is in order. I don't yet understand what they all offer, so I'll be researching them and chronicling my findings here.
Some HTML5 research will probably be in order.
Android too. I'll have to take Android development back up at some point, and that will get some time here.
For now, that's all I'll promise. Stay tuned for the results!
Subscribe to:
Posts (Atom)