WriteLessCode Blog

Final round voting for EuRuKo speakers

2013-05-01T17:00:00Z

With your support, I was honored to get to the list of EuRuKo speaker selection finalists. I'll admit I got a bit pessimistic about my chances first, as I'm standing on the very last place on the list. However, today I got a very encouraging email from a Taiwanese friend who saw me speaking about Netzke at RubyConf Taiwan last year. He wrote me that himself, as well as a few colleagues of his who also were at the conference, have voted for my proposal in the final round, and are wishing me luck. Motivated by this, I decided that it may be worth trying to push it one more last time, so, I'm asking you again to spend 1 minute of your time to login with your GitHub account here, and drag-and-drop my proposal (search for "Netzke") to the "Your selection" area, along with 9 other proposals. And if you could motivate one or two of your colleagues to do the same - that'd be extra-awesome!

The voting ends in 3 days. Can't express how much I appreciate your support!

---
Follow me on Twitter for more updates.

Call for support: Netzke at EuRuKo this year?

2013-04-04T17:00:00Z

For the past weeks, I started receiving more high-quality pull requests for Netzke, so, I realised once more how important it is to grow a skilful community around the project - everyone of us who uses Netzke to build products would eventually benefit from it.

Speaking at conferences is one of the things I'm doing to tell people about Netzke, and I'm trying constantly to raise the bar of the conference level. In case you don't know yet, in May, encouraged by Matz (the author of Ruby) and his team, I'm speaking at RubyKaigi in Tokyo, which I consider a big step forward.

This time I thought, with a little help from you, I might get a chance to speak at EuRuKo.

I want to kindly ask you to spend 1 minute to sign in with your GitHub/Twitter/Google account (one click) and vote up for my proposal. And if you feel you have 5 minutes more, than a comment bellow my proposal would be even more helpful: you might want to ask me to change something in the proposal, or rephrase something, or you can just express your interest in the topic (but, please, back it up with some reasonable argument, as "It's cool, I would like to see it!" would not be enough).

I will also appreciate a personal feedback (below in the comments or at nmcoder @ gmail dot com), even be it simply editorial (I have the right to update the proposal at any time).

Thanks in advance! Together we could pretty much make it.

---
Follow me on Twitter for more updates.

Changing behavior of all Netzke components on the client side

2013-04-03T17:00:00Z

For those folks who didn't understand that my previous post was an April Fool joke - I don't blame you, I may have just failed to make it sound ridiculous enough. Anyways, the reality is kind of opposite to what's advertised there: Netzke development is going as strong as ever, with some great support from the community - in the form of skillful pull requests, interesting suggestions, and joint experiments. Thanks everyone who's been helping moving it forward! Besides, I'm going to present Netzke at RubyKaigi in Tokyo, as well as a few other exciting things meant to give Netzke some exposure, are pending. You may want to follow Netzke on Twitter if you want to stay up-to-date with that news that may not find its way to a blog post.

In meanwhile, in this little tutorial I want to share a tip on how to extend each and every Netzke client-side class, and I'll do that on an example of implementing a custom feedback functionality. As you may know, each Netzke component, at the client side, has a method called netzkeFeedback, which by default displays a little box on the top of the screen:

You may already know that by overriding this method in your component, you can replace the default implementation with whatever you find appropriate - for that specific component. But what if you want to change the way feedback is displayed for all Netzke components at once?

The way to do that is to override the netzkeFeedback method in Netzke.classes.Core.Mixin, which gets mixed-in into each Netzke component. However, this has to be done before any Netzke component class is defined, and for that we can use Netzke::Core.ext_javascripts config option, which other Netzke gems (such as netzke-basepack) use to inject custom JavaScript code (which can be a patch for Ext JS or code shared by multiple components).

A good place to configure Netzke::Core is in config/initializers (e.g. in a file named netzke.rb):

Netzke::Core.setup do |config|
  config.ext_javascripts << "#{File.dirname(__FILE__)}/javascripts/netzke_extensions.js"
end

This will instruct Netzke to load config/initializers/javascripts/netzke_extensions.js along with other initial JavaScript code when a Rails view with Netzke components gets loaded. As I said before, in that file we will override netzkeFeedback:

Ext.define(null, {
  override: "Netzke.classes.Core.Mixin",
  netzkeFeedback: function(msg, options) {
    alert(msg); // anything you come up with
  }
});

That's it. After this every Netzke component will get this custom implementation of the netzkeFeedback method.

In the following tutorial I'll show you how exactly the same technique can be used to change the way Netzke handles session expiration (currently it would simply hint you in the browser console that the onNetzkeSessionExpired method should be overridden). Stay tuned.

---
Follow me on Twitter for more updates.

End of Netzke development

2013-03-31T17:00:00Z

It's been a tough decision. The doubts started to creep in my head after a concise but emotional discussion with one of those people that many of us see as personal heroes:

Slowly, but irreversibly, I started to believe that at the moment I decided to work on Netzke, I took a painfully wrong direction, which was bound to fail. You know, one of those failures that people like to mention when discussing their eventual success. So, in success I believe, but it's time to start from the beginning. My apologies to all the developers that have and have not managed to bring their Netzke-driven projects to production.

---
Follow me on Twitter for more updates.

Testing with CoffeeScript and Mocha

2013-02-24T17:00:00Z

Integration testing of Netzke Core requires running a lot of JavaScript, which, before the rewrite, resulted in numerous custom Cucumber steps that served as wrappers around that JavaScript code. The tests used to read pretty nicely, but the code overhead was too high, and performance very low, as for each spec a page containing the tested component would get reloaded. So, I decided to have a look at JavaScript testing frameworks, and after trying out Jasmine first, decided that Mocha would serve me better (thanks @ptico for pointing me in that direction). After enabling CoffeeScript for writing actual specs, and creating a few custom Ext JS-related helpers, I ended up with specs that read almost as good as Cucumber features, at the same time written in a real programming language, not Gherkin:

describe "Actions component", ->
  it "should handle clicking a button", ->
    click button "Simple action"
    expectToSee header "Simple action triggered"

  it "should show certain buttons disabled", ->
    expectDisabled button "Disabled action"

  it "should not show buttons for excluded actions", ->
    expectToNotSee button "Excluded action"

And for asynchronous scenarios:

describe "Plugins component", ->
  it "should be able to call its server part as defined in PluginWithEndpoints", (done) ->
    click tool 'gear'
    wait ->
      expectToSee header "Response from server side of PluginWithEndpoints"
      done()

You can find the rest of the Mocha features in spec/mocha. Every file from that folder, corresponding to an equally named testing component, is being automatically picked up by the setup and turned into a separate RSpec spec. This way there's generally one Mocha feature for each component being tested. The specs inside that feature are being run all at once, without the need to reload the page. As a result, it's much faster now (also due to the fact that the assertions are now being executed directly in the browser).

Individual features can be run manually in any browser (e.g. in order to analyze the failures) by appending "?spec={feature}" to the URL of a tested component, for example: http://core-test-app.dev/components/Endpoints?spec=endpoints. This will run spec/mocha/endpoints.js.coffee spec on the test/core_test_app/components/endpoints.rb component:

I also want to add that most of the testing components have been re-worked and better named in order to give the developer a clear message of what exactly is being tested. Hopefully this will make understanding Netzke code an easier task, too.

---
Follow me on Twitter for more updates.

Nesting Netzke components

2012-12-15T17:00:00Z

As I mentioned in the end of the previous tutorial, Netzke lets you do much more than just quickly create a grid that seamlessly works with an ActiveRecord model without using any code generators. In fact, Netzke is best suited for making complex one-page web applications that make use of hundreds of data models and implement sophisticated workflows. One of the many techniques that Netzke as a modular GUI framework provides to you, is component nesting. Here I'll show you how easy it is to nest 3 differently configured instances of the Tasks component created before in a tab panel.

Creating tab panel

Assuming you already have the first part of the tutorial up-and-running, let's start by creating a new component called TaskTabPanel, and indicate that its client class should inherit from Ext.tab.Panel:

class TaskTabPanel < Netzke::Base
  js_configure do |c|
    c.extend = "Ext.tab.Panel"
  end
end

Update views/welcome/index.html.erb to show our newly created component:

<h1>Tasks</h1>
<%= netzke :task_tab_panel, height: 400 %>

If we reload our application now, it won't be much, as our tab panel has no tabs yet. We want to see 3 tabs containing our previously created Tasks component, each showing a different subset of tasks.

Nesting Tasks component

We need 2 simple steps to nest a few instances of an existing Netzke component in our tab panel. First, let's declare them as child components inside TaskTabPanel:

class TaskTabPanel < Netzke::Base
  js_configure do |c|
    c.extend = "Ext.tab.Panel"
  end

  component :incomplete_tasks do |c|
    c.klass = Tasks
  end

  component :completed_tasks do |c|
    c.klass = Tasks
  end

  component :all_tasks do |c|
    c.klass = Tasks
  end
end

Now, with child components declared, Netzke gives us 2 choices on how to show them to the user. We could nest them statically in the current component, or dynamically load them on the user request using netzkeLoadComponent client-class method. Let's do the simplest thing now, and add all 3 of them statically as tabs. For this we use Ext JS's usual items property:

class TaskTabPanel < Netzke::Base
  js_configure do |c|
    c.extend = "Ext.tab.Panel"
  end

  component :incomplete_tasks do |c|
    c.klass = Tasks
  end

  component :completed_tasks do |c|
    c.klass = Tasks
  end

  component :all_tasks do |c|
    c.klass = Tasks
  end

  def configure(c)
    super
    c.items = [:incomplete_tasks, :completed_tasks, :all_tasks]
  end
end

Note, that we didn't have to provide the detailed configuration for the tabs, and just used Symbols referring the child components - Netzke does the expansion of those behind the scenes.

Now we have 3 tabs, each with an instance of Tasks component, but they are all named equally and show the same list of incomplete tasks:

Configuring nested components

One way to change this would be by extending our Tasks component 3 times and configure each of them separately, for example, for completed tasks:

class CompletedTasks < Tasks
  def configure(c)
    super
    c.title = "Completed"
    c.scope = {done: true}
  end
end

Then we could use it without any further configuration in TaskTabPanel by specifying c.klass = CompletedTasks inside the component block. However, in this case it would be an overkill, and we can simply configure the 3 nested grids directly in TaskTabPanel:

component :incomplete_tasks do |c|
  c.klass = Tasks
  c.title = "Incomplete"
  c.scope = {done: [nil, false]}
end

component :completed_tasks do |c|
  c.klass = Tasks
  c.title = "Completed"
  c.scope = {done: true}
end

component :all_tasks do |c|
  c.klass = Tasks
  c.title = "All"
  c.scope = nil
end

After reloading the page, we see that the titles indeed have been changed, but our scope configuration didn't take any effect:

The problem is in our previously created Tasks component, namely in the way we specify the scope there:

class Tasks < Netzke::Basepack::Grid
  def configure(c)
    super
    # ...
    c.scope = {done: [nil, false]}
  end
end

As you can see, the scope is set after calling super, where the configuration from the component block is being applied. By moving it before super we'll ensure that it will get overridden from TaskTabPanel, thus making our Tasks component more configurable:

class Tasks < Netzke::Basepack::Grid
  def configure(c)
    c.scope = {done: [nil, false]}

    super
    # ...
  end
end

Naturally, we could also remove it completely if we don't need any default scopes in Tasks

Now we have it fixed:

Discussing the results

You have learnt how to build a simple compound component, and how to make a nested component configurable, which is an alternative to extending a component by sub-classing it. Both techniques have their values in different scenarios, so, it's up to the software designer which approach to choose.

Bonus: load tabs dynamically with Basepack::TabPanel

In our current implementation all the 3 instances of Tasks are being instantiated and added to the tab panel at the page load. This can be a performance issue when you have many tabs each containing a complex Ext JS component as grid. An alternative approach would be to load the nested components dynamically at the moment the user activates a tab for the first time. A dedicated component in netzke-basepack can do just that. All we need to do is to inherit our TaskTabPanel from Netzke::Basepack::TabPanel, and remove the js_configure section:

class TaskTabPanel < Netzke::Basepack::TabPanel
  component :incomplete_tasks do |c|
    c.klass = Tasks
    c.title = "Incomplete"
    c.scope = {done: [nil, false]}
  end

  component :completed_tasks do |c|
    c.klass = Tasks
    c.title = "Completed"
    c.scope = {done: true}
  end

  component :all_tasks do |c|
    c.klass = Tasks
    c.title = "All"
    c.scope = nil
  end

  def configure(c)
    super
    c.items = [:incomplete_tasks, :completed_tasks, :all_tasks]
  end
end

---
Follow me on Twitter for more updates.

At RubyConf Taiwan

2012-12-07T17:00:00Z

My talk went smoothly. For the first time I didn't use Keynote, made my presentation with showoff (you might need to use someone's fork though) - and thus, didn't have a usual opportunity to see presenter notes during the talk. Nor did I miss them. For the first time I felt very confident about my talk - also thanks to the feedback I got from @hasclass just the night before. I published the slides on Heroku - you may want to page through them, they are pretty self-explanatory. As soon as I have access to the video, I'll post an update.

After the talk I came up to Matz (the creator of Ruby) and asked for his opinion. He started with his usual "Well, I'm not a web guy", and then continued: "But I like your concept. If I had to built a webapp like that, I would use your framework". A bit later, showing him the exact text, I asked him for a permission to quote him on netzke.org, and he said "sure". I don't have to tell how excited I am about this. Other guys from the Ruby team seemed also quite impressed, and recommended me to submit a proposal to the rubykaigi in May, with Matz saying "we need this kind of talks at RubyKaigi". Sure enough, I'll give it a try.

But for now, back to work on Netzke v0.8 - it's almost there!

---
Follow me on Twitter for more updates.