RE: This week's community meeting

[Bates, Simon]

At standup this morning, Dana was asking if there would be good places to read 
more about the Smalltalk programming language.

Dan Ingalls' article "Design Principles Behind Smalltalk" is a very nice 
overview of some of the forces and motivations in the design of the language:

http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

In terms of introductions to the actual language itself, it's a little harder 
to find satisfying online material. The best resource, I think, is the book 
"Smalltalk-80: The Language And Its Implementation". A scanned PDF is available 
online and the first few chapters introduce the language:

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

There is a quite nice "Terse Guide to Squeak" (the Smalltalk version I will 
demo today) but it's not an intro or tutorial:

http://squeak.org/documentation/terse_guide/

If I find other good resources, I'll definitely pass them along. (For those at 
IDRC in person, I brought in my copy of the Smalltalk-80 book, if you're 
interested in taking a look.)

Simon

From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Bates, 
Simon [sba...@ocadu.ca]
Sent: Monday, November 23, 2015 8:47 AM
To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
Subject: This week's community meeting

Hi everyone,

For this week's community meeting, we are going to continue with our series on 
Case Studies of User Creativity. On Wednesday we will have a look at Smalltalk 
and other work of Alan Kay and his collaborators.

I'd like to suggest that in advance of Wednesday's meeting, we read one of his 
papers from 1977, written with Adele Goldberg, called "Personal Dynamic Media". 
This paper presents their vision for personal computing and for portable 
computers called "Dynabooks".

I've found 2 versions of the article online: a version with an introduction 
that appeared in a 2003 collection called "The New Media Reader" and a scan of 
the original:

- http://www.newmediareader.com/book_samples/nmr-26-kay.pdf
- https://www.computer.org/csdl/mags/co/1977/03/01646405.pdf

(The whole New Media Reader book is really good and I'll bring it in on 
Wednesday, if anyone is interested in taking a look at it.)

At the meeting I will show a running Smalltalk system and I think it would also 
be awesome to discuss the Personal Dynamic Media paper together.

Looking forward to the conversations on Wednesday.

Simon
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

RE: This week's community meeting

[Bates, Simon]

Another good read on the context and history of Smalltalk is Alan Kay's "The 
Early History of Smalltalk":

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

Simon

From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Bates, 
Simon [sba...@ocadu.ca]
Sent: Wednesday, November 25, 2015 12:41 PM
To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
Subject: RE: This week's community meeting

At standup this morning, Dana was asking if there would be good places to read 
more about the Smalltalk programming language.

Dan Ingalls' article "Design Principles Behind Smalltalk" is a very nice 
overview of some of the forces and motivations in the design of the language:

http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

In terms of introductions to the actual language itself, it's a little harder 
to find satisfying online material. The best resource, I think, is the book 
"Smalltalk-80: The Language And Its Implementation". A scanned PDF is available 
online and the first few chapters introduce the language:

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

There is a quite nice "Terse Guide to Squeak" (the Smalltalk version I will 
demo today) but it's not an intro or tutorial:

http://squeak.org/documentation/terse_guide/

If I find other good resources, I'll definitely pass them along. (For those at 
IDRC in person, I brought in my copy of the Smalltalk-80 book, if you're 
interested in taking a look.)

Simon

From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Bates, 
Simon [sba...@ocadu.ca]
Sent: Monday, November 23, 2015 8:47 AM
To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
Subject: This week's community meeting

Hi everyone,

For this week's community meeting, we are going to continue with our series on 
Case Studies of User Creativity. On Wednesday we will have a look at Smalltalk 
and other work of Alan Kay and his collaborators.

I'd like to suggest that in advance of Wednesday's meeting, we read one of his 
papers from 1977, written with Adele Goldberg, called "Personal Dynamic Media". 
This paper presents their vision for personal computing and for portable 
computers called "Dynabooks".

I've found 2 versions of the article online: a version with an introduction 
that appeared in a 2003 collection called "The New Media Reader" and a scan of 
the original:

- http://www.newmediareader.com/book_samples/nmr-26-kay.pdf
- https://www.computer.org/csdl/mags/co/1977/03/01646405.pdf

(The whole New Media Reader book is really good and I'll bring it in on 
Wednesday, if anyone is interested in taking a look at it.)

At the meeting I will show a running Smalltalk system and I think it would also 
be awesome to discuss the Personal Dynamic Media paper together.

Looking forward to the conversations on Wednesday.

Simon
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

RE: Community Meeting ( Jan 25 ): Using Small Computers (C.H.I.P., Arduino, Raspberry Pi)

[Bates, Simon]

I've uploaded the slides to the wiki:

https://wiki.fluidproject.org/download/attachments/28344721/Small%20Computers%20Community%20Workshop%20Jan%202017.pdf?api=v2

Simon


From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Justin 
Obara [obara.jus...@gmail.com]
Sent: Monday, January 23, 2017 4:32 PM
To: Fluid Work
Subject: Community Meeting ( Jan 25 ): Using Small Computers (C.H.I.P., 
Arduino, Raspberry Pi)



At this weeks https://wiki.fluidproject.org/display/fluid/Community+workshops ( 
January 25, 2017 ) Simon Bates, will be leading a discussion on small computers 
such as C.H.I.P, Arduino, and Raspberry Pi.

Description:
"We will discuss features of the CHIP, how to get started with it, and compare 
it to other single board computers, and micro-controllers, such as the Arduino 
and Raspberry Pi”

See also:

  *   Small Computers Community Workshop January 2016 (wiki 
page)
  *   Small computers community meeting Jan 25 (fluid-work mailing 
list)

Thanks
Justin


Time:
2:30 - 4:00pm ET

Join:
Locally: IDRC Office
Remotely: 
fluid_standup
 Vidyo video conference

Thanks
Justin
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: CouchDB - managing design documents?

[Bates, Simon]

To broaden this topic slightly, I'm thinking that some form of data migration 
automation would also be important to have, in addition to updating design 
documents. For example, if a document structure is modified, we would want to 
have an automated way of updating existing data to the new structure.

Do we have anything currently existing to manage data migration and document 
structure evolution? If not, I'm thinking it would be worth including the topic 
in discussions on managing design documents.

Simon


From: fluid-work  on behalf of Harnum, 
Alan 
Sent: August 28, 2017 11:19:59 AM
To: Tony Atkins
Cc: Fluid Work
Subject: Re: CouchDB - managing design documents?

Hi Tony,

Thanks for the replies – we’ve also been looking at the various Couchapp 
implementations, but have been hesitant both for what you cite below (large 
additional stack of dependencies) and this part of the current CouchDB docs: 
http://docs.couchdb.org/en/2.1.0/ddocs/, which discourages the 
previously-promoted “CouchApps” paradigm that the various CouchApp tools are 
designed to use. My sense is that the various Couchapp projects are not under 
terribly active development in light of this change in CouchDB’s latest 
documentation.

I’d also be an advocate of a Fluid component for capturing views and perhaps 
other configuration aspects of an Infusion application that intends to make use 
of CouchDB - I actually did some experimentation in this direction last Friday, 
which I’ve now cleaned up a bit and added some documentation: 
https://github.com/waharnum/couch-config

In my ideal world I think I’d be able to write a CouchDB configuration for an 
application in pure Infusion rather than pushing JSON around with curl or other 
tools.

From: Tony Atkins 
Date: Monday, August 28, 2017 at 7:32 AM
To: "Harnum, Alan" 
Cc: Fluid Work 
Subject: Re: CouchDB - managing design documents?

Hi, Alan:

Thanks again for starting yet another interesting and important discussion.  
I've had to do a lot of this in my own work, and have alternated between:

  1.  Storing the design documents as raw JSON (mainly for testing).  This is 
similar to the approach used in the example you shared.
  2.  Writing design documents using 
couchapp.
The first approach seems easy enough, but is a bit tedious on a few fronts:

  1.  It's difficult to write even moderately complex functions as escaped 
strings.
  2.  Replacing an existing design document is a bit tedious, as it involves 
either looking up the current document's _rev or DELETEing and then POSTing the 
replacement.
  3.  Although it's possible to require libraries from a design 
document,
 this is pretty hard to manage using raw JSON files.
Couchapp makes each of these easier:

  1.  You just save your functions to a file, which you can run through our 
standard linting and more easily check for syntax errors.  You can even write 
unit tests against the functions you plan to use in your design documents.  
This is especially helpful when developing reduce functions, which can be a 
bear to troubleshoot with CouchDB or PouchDB.
  2.  Although it's trivial, couchapp makes it very easy to update design docs 
repeatedly.
  3.  Couchapp makes it easier to bundle dependencies as part of your design 
document (basically by deploying them to a "lib" or similar directory within a 
design document's directory).
That being said, couchapp is something I have only relied on reluctantly.  I 
don't use it in tests, for example, as it seems a bit much to me to introduce a 
whole stack of dependencies (python, required libraries) just to solve what's a 
fairly simple use case.  Antranig and I have previously talked about building a 
Fluid component to assist with creating design documents, and it seems like a 
good time to broaden and refresh that discussion.

Regardless of whomever else is interested, I would be very happy to work 
together with you (and I'm assuming Antranig) on a ticket outlining the use 
cases in more detail.  Depending on the scope of what we agree is needed, I 
might end up simply building it the next time I need to work on a batch of 
design documents.  I'd also be very happy to help review something someone else 
builds and test that in my own work.

Cheers,


Tony

On Thu, Aug 24, 2017 at 4:16 PM, Harnum, Alan 
> wrote:
Hi all,

We (Greg Moss & myself) are curious to know the opinions of others who've 
worked with it (especially in the context of Infusion / Kettle) about how to 
best manage design documents when using CouchDB as part of an application.

Specifically, what approaches have worked for externalizing design document 
code, ensuring the database has the latest 

Re: CLA service for Fluid GitHub repos

[Bates, Simon]

Something that we may want to take into consideration is the implementation 
language/technology (if we end up hosting an instance ourselves).

cla-assistant is JavaScript Node.js with MongoDB for persistence

and clahub is Ruby on Rails

Simon


From: fluid-work  on behalf of Justin 
Obara 
Sent: April 3, 2018 3:35 PM
To: Fluid Work
Subject: CLA service for Fluid GitHub repos

Hi everyone,

We’ve been talking about simplifying the process of getting CLAs signed for 
some time now. Below I’ll provide a summary of the current process as well as 
the two leading CLA service contenders. We’d really appreciate your feedback 
and suggestions on which approach to take. Also, if you have any question or 
would like further clarification on any part, please let me know.

Thanks
Justin


Current Process - paper based

  *   A contributor is directed to the Fluid 
Licensing
 wiki page to sign either the CLA or the CCLA
  *   The contributor downloads the CLA or CCLA
  *   The contributor fills out the CLA or CCLA and scans or faxes it back to 
the IDRC
  *   We print off a copy of the CLA or CCLA and physically store it

Current Process - paper based

Our current process has been in place for many years now is essentially paper 
based.

Process for a contributor

A contributor is directed to the Fluid 
Licensing
 wiki page to sign either the CLA or the CCLA The contributor downloads the CLA 
or CCLA The contributor fills out the CLA or CCLA and scans or faxes it back to 
the IDRC We print off a copy of the CLA or CCLA and physically store it

Pros

  *   Official document signed with all of the contributors key details filled 
out
  *   physical copy stored

Cons

  *   hard to co-ordinate with contributors, especially if they are in 
different timezones and/or they are contributing a single small change
  *   hard to determine if a contributor has signed a CLA before
  *   our current CLA doesn’t record GitHub ID

CLA Assistant

CLA Assistant is an online service created by the 
GitHub team at SAP. It’s an open source project and we would have the option to 
run our own instance if we choose.

https://github.com/cla-assistant/cla-assistant

Process to setup

  *   One of our repo admins would save a CLA in a Gist on GitHub (I believe it 
can be public or private)
  *   One of our repo admins would login to CLA Assistant with their GitHub 
account and link the repos to the CLA

Process for a contributor

You can test by submitting a PR to 
https://github.com/jobara/cla-assistant-testRepo

  *   contributor submits a PR
  *   CLA Assistant checks if the contributor has signed a CLA. It will mark 
the PR to indicate if it needs to be signed or not. (e.g. 
https://github.com/jobara/cla-assistant-testRepo/pull/1#issuecomment–378346476
 )
  *   If a CLA hasn’t been signed by the contributor, they are also e-mailed a 
notice that they are required to sign it.
  *   The contributor clicks a link from the PR or the e-mail and they are 
shown the CLA and can click a button to sign it using their GitHub credentials.

Pros

  *   Easy to manage, it is all handled automatically
  *   Can import existing contributors with a CSV file
  *   Admins can log into the CLA Assistant interface to get a list of all of 
the contributors who have signed the CLA
  *   Admins can export the list of contributors

Cons

  *   CLA Assistant requires a lot of access to our GitHub repos including 
being able to write to everything

CLAHub

CLAHub is an open source project and online service now 
maintained
 by the Berkman Centre for Internet and Society at Harvard 
University.
 We should also be able to setup our own instance if need be.

https://github.com/clahub/clahub

Process to setup

  *   One of our repo admins would login to CLAHub with their GitHub 
credentials and register each repo
  *   The admin would need to fill in the CLA text for each repo that is added.
  *   The admin can also choose extra fields required to be signed (e-mail, 
name, mailing address, country, phone or Skype, Type “I AGREE”, Type your 
initials, and Corporate Contributor Information)

Process for a contributor

You can test by submitting a PR to