Re: [Pharo-users] Team programming with Smalltalk

[Hilaire]

The best of the two worlds ;)

Le 25/02/2017 à 12:37, Norbert Hartl a écrit :
> To me it is important to have a working image that collects side effects as 
> well as having a process that builds an image from scratch. 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Team programming with Smalltalk

[Norbert Hartl]

Von meinem iPad gesendet

> Am 17.02.2017 um 18:27 schrieb Hilaire :
> 
> You have a very strong point.
> The problem you emphasised, without explicitly naming it, comes from the
> image. Because the image preserves state it is also a great receptacle
> and accumulator for entropies, and as we know entropies only increase,
> never decrease!
> The direct consequence is that, at some time, after some interactions,
> installing code in some order, or installing broken code, an image
> breaks, hit the ground and becomes unusable. The image limit is always
> the chaos (as long as it is used as a living thing and its evolving
> state is preserved, saved),
> 
I do not understand why we should keep entropy low. There are a lot of side 
effects that occur in a program. It is not only code changes, it is also 
creating objects, load external data, etc. Is it possible to draw a clear 
boundary? If not the side effects collect in every image that does something. 
So having an image that collects huge amounts of side effects and still runs as 
expected could be seen as robust system, no? 
Software does not need to fail immediately, it can also when side effects 
collect. This you cannot easily catch with tests. Trying to keep side effects 
low could also mean that you should restart your images often in order to get 
rid of side effects. So keep an image running and operate with it can be seen 
as stress test for the software.
A usual workflow is to commit code changes, having something like jenkins 
building your image from scratch. You then copy the built image to server and 
never save it again. To me it has to do with reproducibility that you need in 
order to have deployment process. 
To me it is important to have a working image that collects side effects as 
well as having a process that builds an image from scratch. 

Norbert
> Entropies always comes with interacting 'living' system.
> 
> So Smalltalk image comes with this downside of entropies. I don't see
> how you can bring argument against that to developer team, because it is
> the Smalltalk weakness, as well its strong point. Very funny.
> 
> Of course you can try to limit entropies. Versioning your image is
> probably what to do, for example host task could save version of your
> image every two hours, daily, etc.
> 
> GNU Smalltalk took an original approach: it ships a minimal image you
> don't modify and you install code on top of it. So really you never save
> your image, entropies remains constant over time. This approach is not
> really possible with Pharo.
> 
> Best wishes
> 
> Hilaire
> 
>> Le 15/02/2017 à 23:43, horrido a écrit :
>> In file-based word, the answer is tests and CI. What is the smalltalk way?
>> And please do not say "It's in the conceptual nature of programming" -- if
>> the scenario makes no sense in the smalltalk world (maybe you are not
>> supposed to have 20 people working on the same project?) please say this.
>> 
>> -
>> 
>> How would you respond? I know Smalltalk can be used in large team
>> programming, but since I personally have no experience with this, I cannot
>> respond intelligently.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Team programming with Smalltalk

[Dale Henrichs]

On 02/20/2017 03:58 AM, Denis Kudriashov wrote:


2017-02-18 8:53 GMT+01:00 itli...@schrievkrom.de 
 >:


 Sadly this is gone or simply only badly implemented. E.g. in
Pharo you
can select a package - fine, but to know, what has been extended
in this
package ?. The name of the method categories also define in which
package this method is located in. Make a type error and the
method goes
into a different package and you will not recognize it. Solutions born
by the idea: how can we make it simple to have a solution this
evening -
and these solutions survive over the years.


It will be changed in Pharo 7 with Calypso. It already shows packages 
instead of categories with start convension.
You guys should really be thinking in terms of projects not packages 
especially for Pharo7... browse project lets you see all classes 
involved in a project, save project saves all dirty packages in project, 
diff project shows all changes for a project ... etc. etc. ...


Dale

Re: [Pharo-users] Team programming with Smalltalk

[Denis Kudriashov]

2017-02-18 8:53 GMT+01:00 itli...@schrievkrom.de :

>  Sadly this is gone or simply only badly implemented. E.g. in Pharo you
> can select a package - fine, but to know, what has been extended in this
> package ?. The name of the method categories also define in which
> package this method is located in. Make a type error and the method goes
> into a different package and you will not recognize it. Solutions born
> by the idea: how can we make it simple to have a solution this evening -
> and these solutions survive over the years.
>

It will be changed in Pharo 7 with Calypso. It already shows packages
instead of categories with start convension.

Re: [Pharo-users] Team programming with Smalltalk

[stepharong]

On 02/15/2017 02:43 PM, horrido wrote:
In file-based word, the answer is tests and CI. What is the smalltalk  
way?
And please do not say "It's in the conceptual nature of programming" --  
if

the scenario makes no sense in the smalltalk world (maybe you are not
supposed to have 20 people working on the same project?) please say  
this.


-
Well I think that being able to use git (disk based SCMS) for managing  
Smalltalk code is one step towards making it practical for large teams  
to work together ...


The major piece that I think is still missing is the ability to have a  
declarative formula/specification for the contents of an image ...


agreed!

The declarative build formula/specification must be something that can  
be shared and versioned.


Today, the closest we can come to this is an ad hoc Smalltalk script and  
that really isn't a good answer


I think that some of the missing building blocks for an image-level  
declarative formula specification are covered in my "Dangerous Liaisons:  
Smalltalk, files, and git "[1] talk, but I really think that there is  
additional work that needs to be done to make it really practical for  
large teams to be able work together on large projects.


Dale

[1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] Team programming with Smalltalk

[stepharong]

For the record I never lost code with MC.
We are managing Pharo since 2008 with MC and it works.

Now I cannot open my old code stored in Envy on my current mac.
While I can dezip MC files.

So you see the devil is in the details.

Re: [Pharo-users] Team programming with Smalltalk

[stepharong]

You see. Pharo is free. Give me money and you will get something much  
better.


For me closed and proprietary tools do not exist anymore. You see I'm  
moving from Keynote for my lecture slides because

they decided that they do not want to load my old lectures :). Tx apple.

I worked with Envy. Now Envy is not good to work in the train and  
deconnected.

I run a local envy base on my machine but it was a bit heavy.

Pharo is moving to git and this is really cool because we do not just save  
files in git but will offer a process and tools around.

Then we will get the associate exposure :)


Stef

Re: [Pharo-users] Team programming with Smalltalk

[stepharong]

Hilaire

What we do and it is working for a lot of projects.
I used the launcher to grab an image built from a CI based on a release  
Pharo image

and a configuration of my project so that I do not have to wait.


Pharo50 + ConfigurationOf/BaselineOf + jenkins => image

PharoLauncher + click => download image

For example for Pillar

Jenkins builds  
40 stable / dev
50 stable / dev
60 stable / dev

based on my configuration and I pick the ones I want to work.
When I commit. bingo the CI sees it and create a new ones with the  
tests run :)


Stef



Building the image from the shell is what I do for DrGeo release.
For development environment it is more in flux but likely should be
done. Any recommended reading on that specific point?

Hilaire

Le 18/02/2017 à 12:54, Pierce Ng a écrit :

Nowadays we are encouraging building images from configs from the CLI or
programmatically, no? Some have mentioned starting with a freshly baked  
image
every day. In my case, I took a fresh image, into which GitFileTree  
loaded
cleanly, then loaded my working stuff through their configs that I've  
been

maintaining.





--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] Team programming with Smalltalk

[Hilaire]

Building the image from the shell is what I do for DrGeo release.
For development environment it is more in flux but likely should be
done. Any recommended reading on that specific point?

Hilaire

Le 18/02/2017 à 12:54, Pierce Ng a écrit :
> Nowadays we are encouraging building images from configs from the CLI or
> programmatically, no? Some have mentioned starting with a freshly baked image
> every day. In my case, I took a fresh image, into which GitFileTree loaded
> cleanly, then loaded my working stuff through their configs that I've been
> maintaining. 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Team programming with Smalltalk

[Pierce Ng]

On Fri, Feb 17, 2017 at 06:27:59PM +0100, Hilaire wrote:
> Entropies always comes with interacting 'living' system.

Good point. I just tried loading GitFileTree into a Pharo 5 image that I've
been using for a while. The image had, to use your term, collected enough
entropy such that the loading failed and the VM hung.

> GNU Smalltalk took an original approach: it ships a minimal image you
> don't modify and you install code on top of it. So really you never save
> your image, entropies remains constant over time. This approach is not
> really possible with Pharo.

Nowadays we are encouraging building images from configs from the CLI or
programmatically, no? Some have mentioned starting with a freshly baked image
every day. In my case, I took a fresh image, into which GitFileTree loaded
cleanly, then loaded my working stuff through their configs that I've been
maintaining. 


Pierce

Re: [Pharo-users] Team programming with Smalltalk

[itli...@schrievkrom.de]

Am 17.02.2017 um 18:51 schrieb Esteban A. Maringolo:
> I've used ENVY for a couple of years, and marginally used Store. Store
> is nothing compared with ENVY, ENVY is far superior. Store is like
> Monticello, but as such it lacks the "Configuration Map" part of it,
> that is offered by Metacello in Pharo/Squeak/GemStone.
> 
> However I find ENVY to be too cumbersome for an agile way of working.

 And another point is, that the way of ENVYs thinking is also available
in the tools they offer for the developer (let it be VW 2.5.2 or
VASmalltalk). Same tools on all platforms.

 This way of thinking is also introduced in the kind of browsers you
have - which offers different ways of views on your projects.

 For me the most and strongest point in the ENVY-Browsers area is the
ApplicationBrowser. Its shows you only the part of the image of a
specific application (package) , which are new classes introduced by you
in this application (package) - but also all the extension methods you
added in this application (package) to classes. That means - programmers
can stay for the whole life of a project - in only this kind of
browsers. A wonderful way of viewing the image.

 Sadly this is gone or simply only badly implemented. E.g. in Pharo you
can select a package - fine, but to know, what has been extended in this
package ?. The name of the method categories also define in which
package this method is located in. Make a type error and the method goes
into a different package and you will not recognize it. Solutions born
by the idea: how can we make it simple to have a solution this evening -
and these solutions survive over the years.

 ENVY for the first time used ? Well I remember, that I was crazy about
this tool - all this versioning, prerequisites etc ... but now after 20
years ? I'm used to the tools available on the Smalltalk market - but
really nice versioning (with several platforms): ENVY is the way to go.

 And the original version had several user interactions implemented -
which have been defined by VASmalltalk (e.g. change the developer role
and make this or that in one click).

 ENVY is also the tool, where I have so much confidence with, because
over the last 20 years I've never seen crashes and data losses. A strong
point for a closed-source software repository.


Marten


-- 
Marten Feldtmann

Re: [Pharo-users] Team programming with Smalltalk

[Dale Henrichs]

On 02/15/2017 02:43 PM, horrido wrote:

In file-based word, the answer is tests and CI. What is the smalltalk way?
And please do not say "It's in the conceptual nature of programming" -- if
the scenario makes no sense in the smalltalk world (maybe you are not
supposed to have 20 people working on the same project?) please say this.

-
Well I think that being able to use git (disk based SCMS) for managing 
Smalltalk code is one step towards making it practical for large teams 
to work together ...


The major piece that I think is still missing is the ability to have a 
declarative formula/specification for the contents of an image ...


The declarative build formula/specification must be something that can 
be shared and versioned.


Today, the closest we can come to this is an ad hoc Smalltalk script and 
that really isn't a good answer


I think that some of the missing building blocks for an image-level 
declarative formula specification are covered in my "Dangerous Liaisons: 
Smalltalk, files, and git "[1] talk, but I really think that there is 
additional work that needs to be done to make it really practical for 
large teams to be able work together on large projects.


Dale

[1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git

Re: [Pharo-users] Team programming with Smalltalk

[Esteban A. Maringolo]

I've used ENVY for a couple of years, and marginally used Store. Store
is nothing compared with ENVY, ENVY is far superior. Store is like
Monticello, but as such it lacks the "Configuration Map" part of it,
that is offered by Metacello in Pharo/Squeak/GemStone.

However I find ENVY to be too cumbersome for an agile way of working.

I found Dolphin Smalltalk X6/7 using PAX source format which is file
based VCS friendly working with Git to be a very good fit, and we used
it in a team of up to 10 commiters to the same repository.

Monticello together with Metacello offers a very good balance, with
integrated tools that enables you to merge and understand the changes.

I haven't used Iceberg yet.


Esteban A. Maringolo


2017-02-15 20:53 GMT-03:00 Brad Selfridge :
> I have worked with VASmalltalk for 20 years and this included projects
> utilizing 10-15 developers. VASmalltalk uses Envy Manager as its VCS. Envy,
> in my opinion, is far superior to anything on the market today where it
> concerns code management. It has open editions, scratch editions, versions,
> application packages, sub-application packages, merges, and doffs. However,
> it was built to be used in an internal organization. It is not usable for
> open source Smalltalk VCS projects such as Git. I believe that Visualworks
> uses a RDBMS product called Store that is similar to Envy. Both of these are
> commercial Smalltalks, however.
>
>
>
> -
> Brad Selfridge
> --
> View this message in context: 
> http://forum.world.st/Team-programming-with-Smalltalk-tp4934508p4934514.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Re: [Pharo-users] Team programming with Smalltalk

[Hilaire]

You have a very strong point.
The problem you emphasised, without explicitly naming it, comes from the
image. Because the image preserves state it is also a great receptacle
and accumulator for entropies, and as we know entropies only increase,
never decrease!
The direct consequence is that, at some time, after some interactions,
installing code in some order, or installing broken code, an image
breaks, hit the ground and becomes unusable. The image limit is always
the chaos (as long as it is used as a living thing and its evolving
state is preserved, saved),

Entropies always comes with interacting 'living' system.

So Smalltalk image comes with this downside of entropies. I don't see
how you can bring argument against that to developer team, because it is
the Smalltalk weakness, as well its strong point. Very funny.

Of course you can try to limit entropies. Versioning your image is
probably what to do, for example host task could save version of your
image every two hours, daily, etc.

GNU Smalltalk took an original approach: it ships a minimal image you
don't modify and you install code on top of it. So really you never save
your image, entropies remains constant over time. This approach is not
really possible with Pharo.

Best wishes

Hilaire

Le 15/02/2017 à 23:43, horrido a écrit :
> In file-based word, the answer is tests and CI. What is the smalltalk way?
> And please do not say "It's in the conceptual nature of programming" -- if
> the scenario makes no sense in the smalltalk world (maybe you are not
> supposed to have 20 people working on the same project?) please say this.
> 
> -
> 
> How would you respond? I know Smalltalk can be used in large team
> programming, but since I personally have no experience with this, I cannot
> respond intelligently.

-- 
Dr. Geo
http://drgeo.eu

[Pharo-users] Team programming with Smalltalk

[Torsten Bergmann]

There is no time on my side to give a full and detailed answer to this as 
a full book could be filled on all the possibilities and options you have in 
Smalltalk. 

One should remember the following few points:

 1. Breaking code is nothing specific to a language. The usual weapon also
in Smalltalk is to monitor if something breaks - for instance by using CI. 
Continuous integration only makes real sense when you have tests.

One should remember that "test first", "unit testing" and "Extreme 
programming" (XP) 
like many other things had their roots in Smalltalk. Because in dynamic 
languages testing using code was and is part of the culture (ranging from 
lively verifying 
with workspace expressions and inspectors up to fully written tests).

The first unit testing framework "SUnit" was written by Kent Beck for 
Smalltalk (SUnit), later he ported it to Java with Erich Gamma on a flight
to OOPSLA OO conference. Java helped to push the popularity afterwards.

Meanwhile also static language enthusiasts have understood that it is 
better to
rely on tests than type checking compilers and they now hurry up to follow
what Smalltalk already had years ago.

One last thing you should try: try to query your system how many test 
methods were 
written. When you solved this easily with a Smalltalk expression retry
this in Java ;)

 2. Commercial Smalltalks which are often used in big projects provide 
solutions 
which are repository based like the famous ENVY (written by OTI, was
in VisualAge for Smalltalk from IBM, now VAST) or Store (VisualWorks). For
more details try the commercial evaluation versions or read [1] or [2].
A screenshot of Envy can be seen in [3]. I worked with ENVY and it is really
good - but mostly only for internal work/teams. If I remember correctly 
ENVY once was also available for VisualWorks (VW) ... but later got replaced
for business or license reasons. I'm not sure about that point.

Cincom developed Store for VW as a replacement which is also nice as it 
allows to work
in an occasionally-connected mode, so work offline and push 
packages/versions later to 
a central team repo. 

In the open source world there are different solutions (including Monticello
which is available for nearly all Smalltalk derivates) or newer solutions 
like FileTree or Iceberg allowing to work with Git. 

The workflow depends on the tool and your requirements.

 3. Often it makes sense to automatically build and regular distribute a fresh 
daily
developer images to the members of your team. This helps in later merging
code. 
For instance Kapital (a big financial project from JP Morgan) works that
way and I've seen that model very often. See [4]

Again nothing special to Smalltalk. In more file based languages it also 
makes 
sense to stay close to the main line and merge as well as resynchronize 
with the
team.

In Pharo for instance we have the PharoLauncher that allows you to download
any (fresh or old) image built provided by the open source community.

 3. Versioning can be done on many levels. Simplest level is the image itself.
Smalltalk not only has an VM and image concept - but also the concept of a 
changes
file. If you evaluate a code expression, create or modify a class or method
in the system this gets logged there.
It prevents you from loosing code and it is easy to restore quickly for 
instance
an earlier method versions/editions that one has implemented.

Most Smalltalks now also work with packages and you can define package
dependencies as well as declaring versions that fit together to provide 
a project, goodie or app (for instance with a Configuration class in 
Monticello)
 
While in file based languages this is often done in an XML file (Maven for 
instance)
or a JSON file in Smalltalk this is usually expressed with objects and 
classes again.
This also makes it more flexible as you can very easily do queries on it or
use refactoring tools to even restructure or reconfigure.

 4. Usage of shared code repositories is very common also in Smalltalk. While 
you
now can also use GitHub, GitLab, Gogs and others with Iceberg and friends 
in Smalltalk
there are also repository systems implemented in Smalltalk itself like
 - SqueakSource (http://source.squeak.org, http://squeaksource.com)
 - SqueakSource3 (http://ss3.gemtalksystems.com)
 - SmalltalkHub (http://smalltalkhub.com)

 5. Beside repositories where code and goodies are hosted one often finds 
registries 
with infos about loadable components. 

Pharo for instance has http://catalog.pharo.org which is accessible also 
directly from the image.  

 5. If you work in a team you can also use a custom update stream. This is how
for instance open source projects like Pharo and Squeak are managed.
So anyone can 

Re: [Pharo-users] Team programming with Smalltalk

[Brad Selfridge]

I have worked with VASmalltalk for 20 years and this included projects
utilizing 10-15 developers. VASmalltalk uses Envy Manager as its VCS. Envy,
in my opinion, is far superior to anything on the market today where it
concerns code management. It has open editions, scratch editions, versions,
application packages, sub-application packages, merges, and doffs. However,
it was built to be used in an internal organization. It is not usable for
open source Smalltalk VCS projects such as Git. I believe that Visualworks
uses a RDBMS product called Store that is similar to Envy. Both of these are
commercial Smalltalks, however.  



-
Brad Selfridge
--
View this message in context: 
http://forum.world.st/Team-programming-with-Smalltalk-tp4934508p4934514.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Team programming with Smalltalk

[Dimitris Chloupis]

Pharo in particular, I cannot speak about other Smalltalks I have not used,
when it comes to VCS its very similar to git actually. It uses source code
files, it distributes them via zip files, it works locally instead of
centralised , it support merges etc.

Pharo works well also with usual VCS because it can export code into source
code files.

The image plays no role in VCS whatsoever because VCS is about code not
data and image is mostly about live data and lesser about live code .

So any tool will and does work with pharo outside the image. Problem arises
with a majority of people that unlike me prefer to stay in the image in
that case you gain more control because you have more pharo code to play
with but you lose a lot of power because we are a small community not able
to compete with behemorth projects like git.

Another interesting thing which Pharo does emphasize is remote debugging ,
though not a Pharo monopoly by a long shot we do have several libraries
that can achieve this and because the image format retains live state and
live code execution its easy to resolve issues.

Besides the image format , the fuel format has the advantage of storing
only fraction of the image. You can email this or share it via git or
dropbox . Like an image a fuel file is a binary file and like the image it
can store live state and live code execution. This way you can isolate live
bugs and share them with your team , each one in its own fuel file .

Ston is also another alternative format which feels familiar for those that
have worked with JSON.

In the end there is nothing really special about Smalltalk , you can
emulate these features in other programming language especially dynamic
pure object orientated ones like Pharo . The difference is that with Pharo
you avoid the custom setup, the extra download of tools and libraries and
the extra glue code required. Of course the fact that those tool have been
around for decades make them more polished and reliable , contrary to
modern that promise the sky and the moon and deilvery very little.

So overall I will say because of live coding features Pharo is ideal for
teams that love to experiment and try ideas on the spot. Especially for
bugs that are hard to catch because they appear in random having the
ability to debug the live code and live state on the spot can really boost
the performance on the team and at the same time utilize all the tool that
coders in other languages can use too.

On Thu, Feb 16, 2017 at 12:48 AM horrido  wrote:

> There's a debate at Hacker News about how Smalltalk is used collaboratively
> in team programming:  https://news.ycombinator.com/item?id=13642947
> 
>
> 'theamk' says:
>
> Sorry, I am at work right now and don't have time to watch videos. Can you
> tell me more about "Smalltalk's own tooling for collaboration and version
> control"? Are you referring to Monticello? I am not insisting on git, but
> Monticello seems pretty limited in term of collaboration. I see commit,
> diff, checkout, and remote pull/push.
>
> Specifically, let's imagine this scenario: we have team of tens of
> programmers working on a project. A new team member joins and accidentally
> breaks the code in non-obvious way. He pushes the code to main repository.
> Next time, everyone else checks out the latest version of the code and
> starts having weird problems. If you had 20 people on team, and they each
> wasted 2 hours because the code was broken, well, you just wasted a week of
> programmer time. How do you prevent it?
>
> In file-based word, the answer is tests and CI. What is the smalltalk way?
> And please do not say "It's in the conceptual nature of programming" -- if
> the scenario makes no sense in the smalltalk world (maybe you are not
> supposed to have 20 people working on the same project?) please say this.
>
> -
>
> How would you respond? I know Smalltalk can be used in large team
> programming, but since I personally have no experience with this, I cannot
> respond intelligently.
>
> Thanks.
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Team-programming-with-Smalltalk-tp4934508.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

[Pharo-users] Team programming with Smalltalk

[horrido]

There's a debate at Hacker News about how Smalltalk is used collaboratively
in team programming:  https://news.ycombinator.com/item?id=13642947
  

'theamk' says:

Sorry, I am at work right now and don't have time to watch videos. Can you
tell me more about "Smalltalk's own tooling for collaboration and version
control"? Are you referring to Monticello? I am not insisting on git, but
Monticello seems pretty limited in term of collaboration. I see commit,
diff, checkout, and remote pull/push.

Specifically, let's imagine this scenario: we have team of tens of
programmers working on a project. A new team member joins and accidentally
breaks the code in non-obvious way. He pushes the code to main repository.
Next time, everyone else checks out the latest version of the code and
starts having weird problems. If you had 20 people on team, and they each
wasted 2 hours because the code was broken, well, you just wasted a week of
programmer time. How do you prevent it?

In file-based word, the answer is tests and CI. What is the smalltalk way?
And please do not say "It's in the conceptual nature of programming" -- if
the scenario makes no sense in the smalltalk world (maybe you are not
supposed to have 20 people working on the same project?) please say this.

-

How would you respond? I know Smalltalk can be used in large team
programming, but since I personally have no experience with this, I cannot
respond intelligently.

Thanks.




--
View this message in context: 
http://forum.world.st/Team-programming-with-Smalltalk-tp4934508.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.