is this workflow incorrect?

i am trying to wrap my head around the development workflow, and i
want to make sure i am doing this as efficiently as possible.

can someone comment on this?

1. develop away in my local image. this includes all classes,
   components, and tests. this does not include editing static files.
2. my static files are served up by a local running version of apache,
   and my resource base is set to point there. at this point, the only
   way i can think of keeping these files wrapped up in the project is
   by using a file based system (git) to version and deploy static
   files.
3. pull my project into a local gemstone to make sure there are no
   problems. i am thinking that a more robust test bed would probably
   be good enough here. if my tests all pass in gemstone, i should be
   good to go.
4. pull project into deployed gemstone, run tests, and let it rip.

there are only few things i don't like about this. i am not sure i
like the idea of having to run a local gemstone and test the app in
two places (gemstone and pharo). since i am new to this, i would
imagine i can drop this step at some point.

i don't like (at all) the idea of running monticello for my seaside
project, and git for my static files. i am thinking i am doing this
incorrectly.

in a perfect world, i would have monticello somehow (without using
file libraries) keep track of my css, image, and js files without having to
run two versioning systems.

i absolutely don't want to serve up static files through seaside, so i
am not sure how to rectify all this.

how are you guys handling these issues?

--
----
peace,
sergio
photographer, journalist, visionary

http://www.ThoseOptimizeGuys.com
http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This is what i would do if I had the time:

The build machine has git and monticello repositories.
In those are copies of all dependencies so you can build
without needing an internet connection.
Use jenkins to build
- a development pharo image;
- a pharo test image to run simple & fast tests
- a linux vm with vagrant+chef solo to test non-smaltalk
 dependencies (running al system & package updates)
use git over ssh to push chef scripts to the vm.
- a linux vm with gemstone with test data
- a linux vm with gemstone with backup data
- diverse clients as windows/mac/linux vm with different browsers
  to run Beach Parasol webtests.

Static files are in the pharo image as far as possible.
The Jenkins build extracts them and puts them as static
files on the linux vm

Stephan
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Thu, Sep 27, 2012 at 9:54 AM, Stephan Eggermont <[hidden email]> wrote:
> This is what i would do if I had the time:
>
> The build machine has git and monticello repositories.


okay. that was alot to digest..

let me stew on all that for some time..

--
----
peace,
sergio
photographer, journalist, visionary

http://www.ThoseOptimizeGuys.com
http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

In your setup you want to be able to
follow new developments as fast as possible.
So you have one vm where you download the newest from
everything, so you know when something starts breaking.
This is essential, as you are much more likely to get
other people to reconsider changes or providing fixes for
the newest developments. If you use old versions, you
basically have to maintain them yourself.

On the other hand, as new stuff tends to be broken a lot,
you probably cannot afford to deploy it immediately to
production. So you need another vm where a combination
runs that you deem to be stable enough. And keep that as
close to the new stuff as possible.

Then you need to be able to test each significant combination
of browser/os on the client side. Browser versions change a lot,
so you might need a few of them.

Then there are the differences between smalltalk environments.
You need to make sure that what you did on Pharo works on
Gemstone.

And last there is your own development and that of your team
members.

Stephan
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sergio,

You might want to checkout some of my recent work with Metacello, Git and GitHub....

The short answer is that it is possible to use git for your development ... storing monticello packages and static files (js, etc.) in git is definitiely doable.

The long answer is that I've been working in Git/GitHub since late January. The FileTree[1] project makes it practical to store Monticello packages on disk and therefore makes it possible to stash your smalltalk code on Git and use Github. I have recently announced[2] a Metacello Preview release (1.0.0-beta.32.3) that adds git/github support to Metacello[3],[4].

If you take a look at the amber-skeleton[5] and take a look at the set up instructions[6] for the pharo server, you'll see that I've used git to build the directory structure around the server (in this case Pharo) in addition to all of the source code, scripts and documentation ...

Regarding the duplicate pharo/gemstone testing, I'll just say that a little bit of paranoia goes a long way:) The Pharo and GemStone environments aren't exact copies of one another, so it is just prudent to make sure that things work as well in GemStone as they do in Pharo ... I don't think you'd want to skip the steps, but automating the steps would be a big advantage ... along those lines, TravisCI provides continuation integration support tied to GitHub push/pull requests ... automated builds and tests, that I am using for all of my pharo work ... right now Travis only supplies 32 bit environments, but as soon as a 64 bit environment shows up I will be using Travis for GemStone as well ...

Dale

[1] https://github.com/dalehenrich/filetree
[2] http://gemstonesoup.wordpress.com/2012/09/18/metacello-1-0-beta-31-1-5-brewed/
[3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[4] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScriptingAPI.md
[5] http://gemstonesoup.wordpress.com/2012/04/22/amber-skeleton-lookout-kaliningrad/
[6] https://github.com/dalehenrich/amber-skeleton/blob/master/server/pharo/README.md
----- Original Message -----
| From: "sergio_101" <[hidden email]>
| To: "Seaside - general discussion" <[hidden email]>
| Sent: Thursday, September 27, 2012 5:44:47 AM
| Subject: [Seaside] is this workflow incorrect?
|
| i am trying to wrap my head around the development workflow, and i
| want to make sure i am doing this as efficiently as possible.
|
| can someone comment on this?
|
| 1. develop away in my local image. this includes all classes,
|    components, and tests. this does not include editing static files.
| 2. my static files are served up by a local running version of
| apache,
|    and my resource base is set to point there. at this point, the
|    only
|    way i can think of keeping these files wrapped up in the project
|    is
|    by using a file based system (git) to version and deploy static
|    files.
| 3. pull my project into a local gemstone to make sure there are no
|    problems. i am thinking that a more robust test bed would probably
|    be good enough here. if my tests all pass in gemstone, i should be
|    good to go.
| 4. pull project into deployed gemstone, run tests, and let it rip.
|
| there are only few things i don't like about this. i am not sure i
| like the idea of having to run a local gemstone and test the app in
| two places (gemstone and pharo). since i am new to this, i would
| imagine i can drop this step at some point.
|
| i don't like (at all) the idea of running monticello for my seaside
| project, and git for my static files. i am thinking i am doing this
| incorrectly.
|
| in a perfect world, i would have monticello somehow (without using
| file libraries) keep track of my css, image, and js files without
| having to
| run two versioning systems.
|
| i absolutely don't want to serve up static files through seaside, so
| i
| am not sure how to rectify all this.
|
| how are you guys handling these issues?
|
| --
| ----
| peace,
| sergio
| photographer, journalist, visionary
|
| http://www.ThoseOptimizeGuys.com
| http://www.CodingForHire.com
| http://www.coffee-black.com
| http://www.painlessfrugality.com
| http://www.twitter.com/sergio_101
| http://www.facebook.com/sergio101
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sergio,

I guess I'd try and start development right in Gemstone and only use
Pharo for experiments with Seaside and stuff. There are quite a few
nifty differences between the two, and you should try to get a feel for
the transaction behavour of Gemstone in ordr to not make really stupid
mistakes. In addition, think about test data. How would you transport a
set of test data between GemStone and some Pharo image? Not that there
are no solutiuons for this, but they eat up your time and energy,
however clever they sound.

So my advice would be to install a development GemStone and a test
GemStone in your development environment. Pharo is great, don't get me
wrong. But if you want to deploy on GemStone, use GemStone as early as
possible. If portability is a concern (you don't say so, however), you
can use Pharo, of course.

Metacello, Monticello, git. I think Dale's work with FileTree is a thing
that we should absolutely keep an eye on. I like the idea of storing
Smalltalk code in git, be it as a primary repository or some backup or
place to exchenge code with others. It would be so cool if we finally
had a format and technology which all Smalltalks can access and use,
even if portability is a separate issue. Today, just loading/importing
code can be hard, so this is a first step.

I'd like to be very clear about File Libraries and files in the image.
You really shouldn't bother. It's extremely easy to export the files to
a file system when it comes to deployment, and you'll have to work with
RewriteRules and stuff for your deployment environment anyways when your
app is ready.
The problems you'll face with things you don't even imagine they exist
today will make this problem area look like a sunday afternoon walk on
the beach. For development, having all and everything in your image is
extremely handy, and a simple rewrite rule in your web server will make
it easy to redirect all requests for files to the file system with zero
changes to your Smalltalk code. The file library can still be in your
image and will never have to serve anything. Gi with file libraries and
worry about this later. Just my 2 cents on this one.


hth

Joachim




Am 27.09.12 14:44, schrieb sergio_101:

--
-------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

sergio_101 <sergio.rrd <at> gmail.com> writes:

>
> i am trying to wrap my head around the development workflow, and i
<snip>
Thanks to Sergio, we are dealing like grownups in how to deal with development
with Smalltalk. I love this thread and will eagerly follow.
Many years ago I did development with Smalltlak under the cocoon of IBM and they
held the tool stack very tightly and well.,
Thanks you guys, I am revisiting Pharo/Seaside as a newbie and have failed due
to my lack of knowledge (documentation and examples are mired in Seaside 2.8)


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Thanks you guys, I am revisiting Pharo/Seaside as a newbie and have failed due
> to my lack of knowledge (documentation and examples are mired in Seaside 2.8)
>

hi, intrader..

i should also point out that this is maybe my third time visiting
smalltalk/seaside in a few years. i wrestle with it, give up, and go
back to using rails for all my projects..

this time was a bit different. i have spent the past year seriously
studying software development. not studying language syntax and all
that stuff, but the underlying ideas of design and best practices. it
seems like everything always comes back to smalltalk.

this time, i made up my mind that i was going to approach seaside
without any previous notions of MVC web design or anything that other
frameworks use to approach the web problem. i was going to learn
seaside on its own terms..

at this point in my life, i have crawled around so much code, i have a
much better grasp of approaching the web problem. i didn't bring this
baggage to seaside this time.

it turns out that seaside is MUCH easier to grasp this time. the trick
is.. you have to let go of your expectation of what happens a the web
interface. it is pretty much like desktop app programming. web server
interaction is handled for you, and you don't really have to think
about it (ever)..

anyway.. just wanted to let you know that i am right there with you..
this isn't my first attempt at learning seaside..  but this time, i
think it's sticking..


--
----
peace,
sergio
photographer, journalist, visionary

http://www.ThoseOptimizeGuys.com
http://www.CodingForHire.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside