<br><div class="gmail_quote">Forwarded to mail list.<br><br>What I do do is use DOM inspectors and such as much as possible.<br>I actually work ON the site, in a test environment without touching the site, by using things such as Firebug for Firefox.<br>
It works pretty well, and I don't have the duplication problems that you mentioned. I can immediately see what my change is going to do, then I can just put what I've done, into the live site itself.<br>
<br>Things like javascript I put in straight away because I don't know how to test those in firebug. If you repload the page you lose your changes, and js requires reloading to work properly as far as I understand.<br>

<br>The down side of how I work, is that if I close that window, my changes are gone gone. That's happened a few times.<div><div></div><div class="h5"><br><br><br><br><div class="gmail_quote">On Sun, Feb 6, 2011 at 7:17 AM, J. Alves <span dir="ltr"><<a href="mailto:alvesjmp@gmail.com" target="_blank">alvesjmp@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I see. I guess that is a problem with a test site, if it suddenly gets<br>
completely overhauled and the old goodies lost as you describe. How<br>
stable is OCAL now, in terms of having plans on changing platforms<br>
again in the next, say, two years?<br>
<br>
Also of course there's the time waste of doing something on the test<br>
site and then transplanting it to the live site, I know how it is. The<br>
way I sort of solve that in my web apps is to just change to which<br>
version I am pointing at the time, which is easy and quick to do. So<br>
let's say I have app_A which points to DB_A and app_test which points<br>
to DB_test (which are copies of the _A versions, although the DB does<br>
not need to be current, just to hold some representative data). I mess<br>
around with app_test and modifications go to DB_test. If everything<br>
woks as expected and data does not get corrupted or lost, I then<br>
immediately put app_test in app_A's place. In the future, when I'm<br>
thinking of modifications, I copy app_A to app_test and tell it to use<br>
DB_test and modify that. Works for one person, but would it work with<br>
multiple developers? Of course that's what version control was<br>
invented for, but I don't have experience on using that for<br>
multi-developer cases and don't know if it would be<br>
desirable/overkill/whatever in OCAL's case. Just throwing ideas out<br>
there.<br>
<br>
Of course, when the modification is trivial or has little potential<br>
bad consequences (i.e. it would damage data) I just do it on the live<br>
version of my apps and pages.<br>
<br>
Anyway, even if a test site is undesirable, if possible a downloadable<br>
OCAL site (DB schema included) for developers would be good for<br>
noobies to get up to speed quicker before messing with the real thing.<br>
<br>
Or, if the general consensus is that the risk is acceptable, then<br>
we'll just hack away with reckless abandon! OK, maybe not that much...<br>
:-)<br>
<br>
Cheers<br>
<font color="#888888">J<br>
</font><div><div></div><div><br>
On Sat, Feb 5, 2011 at 12:51 PM, chovynz <<a href="mailto:chovynz@gmail.com" target="_blank">chovynz@gmail.com</a>> wrote:<br>
> I don't think you can do any worse that what happened yesterday. :)<br>
><br>
> For the most part, I'd suggest you relax about not comfortable about working<br>
> on a live site. That's one of the reasons why I put the "chovynz is<br>
> working!" sign up, to make people aware that weird things could happen.<br>
><br>
> I do understand the thinking though, which is why it's taken me this long to<br>
> get to where I am with coding OCAL. However, now that I've done editing ON<br>
> the live site for awhile, I now think that a test site is a waste of time. I<br>
> mean we already had a BETA site with so much more features and fixed bugs on<br>
> it, then when this one came through I was disappointed to see most of the<br>
> changes was lost.<br>
><br>
> You have good thoughts, though. All I'm doing is commenting on the idea. I'm<br>
> against having a test site, and just want other devs to just jump in on the<br>
> live site. If my opinion weighs anything, my vote is against, but i don't<br>
> want the discussion to stop. Ultimately the choice is Jon's/server owners.<br>
><br>
> Convince him either way.<br>
><br>
><br>
> On Sun, Feb 6, 2011 at 5:54 AM, J. Alves <<a href="mailto:alvesjmp@gmail.com" target="_blank">alvesjmp@gmail.com</a>> wrote:<br>
>><br>
>> By the way, I was wondering about that these days. Maybe this has been<br>
>> discussed before and I missed it, in which case I apologize for the<br>
>> repetition... Just let me know and I return to under me bridge. :-)<br>
>><br>
>> I am thinking of trying to learn Aiki, php and all that to be able to<br>
>> help with the code side of things. But I would never feel comfortable<br>
>> touching the live site even after I'm fluent in those technologies,<br>
>> let alone during the learning process, so I was hoping there was a<br>
>> parallel code or site for this type of activity. You know, a sort of<br>
>> private mirror of OpenClipart's code (not necessary to have the full<br>
>> database, although that would be nice too) where people would develop<br>
>> and tweak without worry that the main site was getting screwed up (as<br>
>> its looks were when I looked 5 min ago, for example). Then, when we<br>
>> were confident that the modifications are working and nothing is<br>
>> getting damaged in the DB by our actions, then it would be time to<br>
>> patch the old code with the new stuff. That's what I do with my little<br>
>> web apps that are not important and don't have any traffic beyond two<br>
>> or three labs and not 1,000s of visitors a day like OCAL. Is anything<br>
>> like that in place for OCAL? I suspect not. The next best alternative<br>
>> of having a working development branch of the site would be to give<br>
>> people the full code for installing at their home server so they can<br>
>> work on it there (is that available? I'd like that). Then they would<br>
>> send the modifications either to the main site or to a (few) central<br>
>> person(s) who'd integrate the code with the live site every once in a<br>
>> while.<br>
>><br>
>> Imagine for example if I try to solve the tags problem or try to<br>
>> implement the "idea mill" I registered in the blueprints (is that the<br>
>> place for ideas of new features?) or whatever, and in the process ALL<br>
>> tags for ALL cliparts get mangled to something unexpected and useless.<br>
>> That would be a huge disaster and I'd have to hide from librarians for<br>
>> the rest of my life. :-) OK, I suppose there are backups, but still a<br>
>> pain in the proverbial.<br>
>><br>
>> Cheers<br>
>> J<br>
>><br>
>> On Sat, Feb 5, 2011 at 6:02 AM, Bassel Safadi <<a href="mailto:bassel.safadi@gmail.com" target="_blank">bassel.safadi@gmail.com</a>><br>
>> wrote:<br>
>> > it seems a server side problem, I emailed osuosl about, hope to get it<br>
>> > back<br>
>> > soon<br>
>> ><br>
>> > On Sat, Feb 5, 2011 at 5:43 AM, chovynz <<a href="mailto:chovynz@gmail.com" target="_blank">chovynz@gmail.com</a>> wrote:<br>
>> >><br>
>> >> To Jon or Bassel<br>
>> >><br>
>> >> I hope you have backups.<br>
>> >> I'm tired of the interlinked problems.<br>
>> >><br>
>> >> The only thing I did was change one value in the css.<br>
>> >> div.r-img-i {width:110px;}<br>
>> >>   to<br>
>> >> div.r-img-i {width:100px;}<br>
>> >><br>
>> >> And the whole site crashed. This after successfully already unwinding<br>
>> >> much<br>
>> >> of the css spagehtti code. Fucking stupid.<br>
>> >> Now, I can't login to admin, and no-one can see the site. Nothing I can<br>
>> >> do<br>
>> >> from my end. Someone with ssh access is going to have to fix whatever<br>
>> >> went<br>
>> >> wrong.<br>
>> >><br>
>> >> I was editing the "main" widget css at the time. I hope you've got a<br>
>> >> log<br>
>> >> file of what happened, because I'm sure I did nothing that would cause<br>
>> >> this,<br>
>> >> since I was only playing with the layouts of the cliparts that were<br>
>> >> displayed on the main page to get them to fit better. If i did do<br>
>> >> something,<br>
>> >> then I need to know what it was, so that I can avoid that in the<br>
>> >> future.<br>
>> >><br>
>> >> I'm going to take a break. sheesh.<br>
>> >><br>
>> >> --<br>
>> >> Cheers<br>
>> >> Chovynz<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Bassel Safadi<br>
>> > <a href="http://bassel.ws" target="_blank">http://bassel.ws</a><br>
>> > <a href="http://aikilab.org" target="_blank">http://aikilab.org</a><br>
>> > Global +1 323-545-3855<br>
>> > Singapore +65 93488349<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > clipart mailing list<br>
>> > <a href="mailto:clipart@lists.freedesktop.org" target="_blank">clipart@lists.freedesktop.org</a><br>
>> > <a href="http://lists.freedesktop.org/mailman/listinfo/clipart" target="_blank">http://lists.freedesktop.org/mailman/listinfo/clipart</a><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
>> João Marcelo Pereira Alves (J) - Genomics, Molecular Phylogeny and<br>
>> Evolution<br>
>> Dept. Microbiology & Immunology - MCV/VCU - Richmond, VA, USA<br>
>> f. 1-804-828-3897 / 804-852-1234 - <a href="http://bioinfo.lpb.mic.vcu.edu" target="_blank">http://bioinfo.lpb.mic.vcu.edu</a><br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
> Chovynz<br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
João Marcelo Pereira Alves (J) - Genomics, Molecular Phylogeny and Evolution<br>
Dept. Microbiology & Immunology - MCV/VCU - Richmond, VA, USA<br>
f. 1-804-828-3897 / 804-852-1234 - <a href="http://bioinfo.lpb.mic.vcu.edu" target="_blank">http://bioinfo.lpb.mic.vcu.edu</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br>Cheers<br><font color="#888888">Chovynz<br>
</font></div><br><br clear="all"><br>-- <br>Cheers<br>Chovynz<br>