tag:blogger.com,1999:blog-2691799628167753841.post2726805890393519048..comments2017-12-06T01:17:39.916-05:00Comments on Digging in the dirt: A year goes by... Bob Nemechttp://www.blogger.com/profile/09778957926861701906noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-2691799628167753841.post-26053019330485895582017-12-06T01:17:39.916-05:002017-12-06T01:17:39.916-05:00simple and useful Thanx...
outsource invoice proce...simple and useful Thanx...<br /><a href="http://invoice-processing-services.blogspot.com/" rel="nofollow">outsource invoice processing services</a><br /><br />Anonymoushttps://www.blogger.com/profile/16222440434277741252noreply@blogger.comtag:blogger.com,1999:blog-2691799628167753841.post-91076492499679854012016-11-24T21:09:43.405-05:002016-11-24T21:09:43.405-05:00Great story!
"And it's a general problem...Great story!<br /><br />"And it's a general problem to anyone advocating an unconventional technology."<br /><br />This is true of anything that isn't Java, C#, Python, C++, R. Businesses are very conservative. They generally like to play it safe.<br /><br />So it's not just Smalltalk that faces this problem but also Clojure, Elixir, Julia, Kotlin, Rust, etc. Every new technology must push whatever advantage it has in order to overcome management resistance.<br /><br />Yes, I know, Smalltalk isn't "new" but the same narrative applies.Richard Kenneth Enghttps://www.blogger.com/profile/05644263534712181856noreply@blogger.comtag:blogger.com,1999:blog-2691799628167753841.post-22080241729407245102016-09-17T01:56:48.715-04:002016-09-17T01:56:48.715-04:00Interesting read. I am in a somewhat similar place...Interesting read. I am in a somewhat similar place, with s/Java/PHP/g<br /><br />My current take is to use Pharo for managing key business data areas and make a REST service in front of them.<br /><br />Not perfect but moving all to GS is just too huge to swallow for some people.Philippe Backhttps://www.blogger.com/profile/07431889923064730789noreply@blogger.comtag:blogger.com,1999:blog-2691799628167753841.post-65288159939083840332016-09-14T08:20:27.410-04:002016-09-14T08:20:27.410-04:00We get the 'liveliness' of fat client even...We get the 'liveliness' of fat client events with onClick and onBlur ajax callbacks. onClick / onChange trigger a div render that enables things like the Save / Cancel buttons. onBlur triggers a GS call to get domain changes based on the pending update (like when changing a start date adjusts the end date). Each call to GS is RESTful, with only the 'save' action doing a commit. Most of the onBlur interactions are under 50ms; the vast majority under 100ms. <br /><br />But we do have the occasional busy user conflict which we plan to correct with our next big change, which is to move the Seaside code from VW to GS. We didn't do that originally because we needed the VW web servers to support a hybrid web / fat client implementation. Things would have been so much simpler if we'd deployed fully on GS from the start. <br /><br />That's the kind of refactoring I'd love to challenge a java team to do: move your web code from a web server to an active database. I figure it will take us about three months. <br /><br />Big fan of VA... still the best looking dialect out there, next to Dolphin. Bob Nemechttps://www.blogger.com/profile/09778957926861701906noreply@blogger.comtag:blogger.com,1999:blog-2691799628167753841.post-25423287442461151382016-09-14T05:58:19.587-04:002016-09-14T05:58:19.587-04:00I work with VA Smalltalk, on an application that m...I work with VA Smalltalk, on an application that makes intensive uses of events. I don't think that Seaside/JavaScript can ever replicate that. How are you finding replicating the events on the fat client (I assume there are events being used) with Seaside/JavaScript?vinrefhttps://www.blogger.com/profile/11934253578270897654noreply@blogger.com