Blog

Introducing GTSpotter: a moldable interface for spotting objects

Search is pervasive in software development. Yet, most IDEs treat it somewhat as a side issue. As a consequence, you get multiple different search interfaces within the same environment, each of them being limited to a specific search, and not being composable with other search intefaces.

Alex Syrel, Andrei Chis and I decided it is time to change this state of facts, and we are happy to announce the first public version of GTSpotter, a novel interface for spotting objects that is part of the Glamorous Toolkit.

We had two broad goals when developing the GTSpotter interface:

  1. Provide a uniform yet moldable interface that can work on any object,
  2. Handle searching through arbitrary levels of object nesting.

Let’s take a closer look.

Spotting packages, classes, pragmas, implementors

Searching for classes or packages is a common code search requirement. Although very similar in nature, these two searches are too often supported through separated search interfaces. GTSpotter integrates them easily in one. In the example below we see the basic interface that is triggered via Cmd+Enter. On top, the user can enter a textual query, and below the search is executed through multiple search categories. In our case, entering GTSpo, leads to matching 39 classes (of which only 5 are shown) and 1 package. For each element, the matching substring is underlined.

The interface is fully controllable through the keyboard. The user can move with ArrowUp/ArrowDown between items or Cmd+Shift+ArrowUp/ArrowDown through categories. At the same time, the search field has the focus, so the user can switch seamlessly between selecting items and refining the search. Pressing Enter reveals the code browser.

Classes-packages.png

While packages and classes are typical structural entities, annotations can be equally important. GTSpotter searches for Pharo pragmas in the same interface. In this case, pressing Enter opens an inspector on the PragmaType object.

Pragmas.png

Searching for implementors is another common code search use case. Until now, the way to search for implementors in Pharo is to open a Playground, enter a the symbol, press Cmd+m and then close the Playground window. Tedious. GTSpotter makes it easier.

Implementors.png

Spotting menu items

But, it's not just code that is interesting for search. Finding a tool is a search activity as well. That is why, the main GTSpotter offers, by default, the list with the items from the World menu.

Default-menu.png

GTSpotter matches substrings. For example, searching for m b gets to the System Browser menu item, and pressing Enter spawns the browser. In essence, this produces a simple shortcut scheme.

System-browser-menu.png

Spotting past Playground pages

GTPlayground remembers all snippets ever used within the image. This is nice, but it can quickly become hard to find a previous snippet. That is why, GTSpotter makes this list searchable. For example, a common use of Playground is to enable the triggering of a Gofer loading script. Searching for Gofer new reveals all snippets used in the past. Pressing Enter reveals a Playground populated with the desired code.

Playground.png

Spotting public Playground pages

Since a while, the GTPlayground has the ability of publishing the contents to the sharing service available at: http://ws.stfx.eu. However, until now, the playground offered no easy way to load the contents of a published page. GTSpotter fixes the situation: simply pasting the url offers an object with the remote page. Pressing Enter opens a playground with the page contents.

Stfx.png

Spotting the last spotted objects

GTSpotter can find various types of objects rather fast. Yet, often we just want to get to the objects we just visited recently. It is for this reason that GTSpotter offers the history of previously spotted objects by default. For example, the picture below shows a history of 5 most recent objects.

History.png

Diving inside an object

Typical IDE search tools behave like general search tools in that they offer only one level of search. However, software systems have structure, and we often need to be able to search inside a found object. To this end, GTSpotter allows the user to dive in an object and continue searching through the same interface. This is accomplished by pressing Cmd+RightArrow.

For example, the below picture shows the case of going inside the GTSpotter class. The context of the current search is shown in the breadcrumb on top of the window. For this method, the user can search through class related facts such as methods, variables or references.

Dive-class.png

Diving in a method, again offers the same interface through which the user can search for senders or implementors.

Dive-class-method.png

Diving in a sender reveals the senders and implementors. Thus, this simple interface provides the basic block for replacing other interfaces that are dedicated to showing the list of senders, implementors or references in a separate window.

Dive-class-method-sender.png

But, GTSpotter is about objects, not about code. To exemplify the implication of this, let’s consider the typical use case of looking for a file somewhere in the directory structure inside the current directory. In the below picture, the main GTSpotter finds a directory.

Directory.png

Diving in the directory, allows the user to continue searching for deeper items.

Dive-folder-folder.png

Committing to Monticello from GTSpotter

Many development actions can be seen as search activities. Let’s consider the typical case of committing the changes of a package. First, we have to find the dirty package. Then, we have to find and choose the target repository, and then we commit.

These actions can be done directly from GTSpotter. When a dirty package exists in the image, it appears by default in the main GTSpotter in a separate searchable category.

Dirty-package.png

Diving in the package, reveals the repositories.

Dirty-package-repository.png

Selecting a repository and pressing Enter triggers the commit dialog. This is but an example of how a search interface can change established workflows. This is certainly an area that has great potential.

Diving inside a category

Let’s search for do:. The search raises 81 results. However, only 5 of them are shown.

Do-implementors.png

How can we get a hold of Collection>>do: method?

To do this, GTSpotter offers an extra action: diving in a category. Pressing Cmd+Shift+ArrowRight dives in the collection object containing only the items from that category. Thus, we can continue refining the search inside the category.

Refining a search can be applied to any category.

Dive-category-do-implementors.png

Spotting your objects

The existing implementations already comes with more than 30 various categories that support a rather extensive set of common search actions. However, the true power of GTSpotter comes from it being moldable.

Like with the GTInspector, each category is defined through corresponding extension method in the object representing the current search context.

By default, the main GTSpotter opens on itself. Thus, all the top level categories are defined as extensions of the GTSpotter class. For example, searching for all classes in the image, is achieved as follows:

GTSpotter>>spotterForClassesFor: aStep
     <spotterOrder: 10>
     aStep listProcessor
               allCandidates: [ Smalltalk allClasses ];
               title: 'Classes';
               matchSubstring;
               itemIcon: #systemIcon

Similarly, searching for the instance side methods inside a class, is achieved through an extension method of Class:

Class>>spotterMethodsFor: aStep
     <spotterOrder: 10>
     aStep listProcessor
               title: 'Instance methods';
               allCandidates: [ self methods ];
               itemName: [ :method | method selector ];
               matchSubstring

That means that you can get your objects to be equally searchable with just a handful of lines of code.

Summary

GTSpotter offers a novel interface of getting hold of an object.

If the GTPlayground and GTInspector enable a deep conversation with an object, the GTSpotter makes it possible to start that conversation quickly.

Posted by Tudor Girba at 7 December 2014, 2:03 pm with tags tooling, moose, pharo, analysis link
|

Humane assessment keynote and tutorial at "Be Fast & Curious", Cluj

Next week, on December 13, I will have the pleasure of giving a keynote and tutorial around humane assessment and Moose at the Be Fast & Curious event in Cluj, Romania.

The event is organized by 3Pillar Global. This is the first time that I am talking about these topics in Romanian, so this will actually pose a little challenge. But, considering the fact that the event poster has my head on it, I will certainly enjoy it.

If you are in the neighborhood, come and join us (the registration is free).

Poster.png

Posted by Tudor Girba at 4 December 2014, 11:03 pm with tags presentation, assessment, moose link
|

Deep Roassal integration in the Moose Finder

Since quite a while, prototyping Moose visualizations (originally using Mondrian and more recently Roassal) was mainly supported through the concept of an Easel: a dedicated editor that allows one to prototype and preview the visualization.

Easel.png

While developing the GTInspector we discovered that we can also integrate Roassal visualization directly in the analysis workflow, simply by making the Roassal builders be able to display themselves. I took the lesson and extended the Moose Finder with that ability.

For example, in the picture below, we see a workflow formed of four steps. The first pane shows script that is applied on a model of a Pharo system (namely, Glamour). The result is shown to the right. Selecting a circle opened the corresponding class in the third pane. There we played with another script to show relationships between attributes and methods from the class, and the fourth pane shows the preview.

Finder.png

One thing the easel offers is a way to obtain examples. To support that in the context of the Moose Finder, we now have another option. Inspecting the class of a builder (e.g., RTMondrianViewBuilder) or of the raw RTView offers the examples. Clicking on an example shows the actual visualization.

Eg.png

The more interesting thing is that next to the visualization, we also get the ability of looking at the actual source code of the example.

Eg-source.png

All in all, visualizations just got even more integrated in the analysis workflow supported by the Moose Finder, the default model browsing interface.

Posted by Tudor Girba at 1 December 2014, 11:25 pm with tags moose, analysis, tooling link
|

Survey: How do we use object inspectors, anyway?

As you might have noticed, the GTInspector advances a new breed of inspectors featuring functionality that does not exist anywhere else. In order for us to understand the impact of this concept, we kindly invite you to participate in a survey.

This is a short survey and should take you no more than 10 minutes to complete.

Please, fill the survey up.

Posted by Tudor Girba at 10 November 2014, 7:18 am link
|

Software assessment lecture at the University of Bern (2014)

On October 15, I gave a lecture at the University of Bern on software assessment. The lecture was split into three parts:

  • an introduction on why we need to pay serious attention to software assessment,
  • a Moose Jazz session showing multiple live case studies, and
  • a concluding session on why custom tools are essential in software engineering.

The most exciting part, at least for me, was the second one. Instead of offering recounts of case studies, I showed these cases live. The cases ranged from:

  • multiple queries on a Java system,
  • parsing and analyzing a proprietary scripting language,
  • spotting performance problems by analyzing log files,
  • reasoning about development issues by querying issue tracker, and
  • inspecting the file system.

All of these tools were developed using Moose and they were produced in a short amount of time.

On the one hand, it’s nice to be able to show solutions to real problems live using a mature tool produced mainly by researchers. On the other hand, the very fact that all of these problems were solved with one uniform set of mechanisms attest the fact that assessment is indeed a generic skill that once learnt can be utilized in many different contexts.

At the end, I remarked that assessment is not deemed an interesting enough subject of conversation to capture the attention of engineers even though it is the most expensive and pervasive activity in software development.

So, I asked the audience if they found the demos exciting. I did not ask about interesting, I asked if they were exciting. And they all said yes.

You see, assessment is exciting. It only takes us to look at it properly.

Posted by Tudor Girba at 26 October 2014, 8:50 pm with tags assessment, presentation, moose link
|
<< 1 2 3 4 5 6 7 8 9 10 >>