Panjang banget 'Rie. Lu kayak programmer __selain ruby__ aja posting imel
forward panjang-panjang dan susah dimengerti :D
Gw lagi baca buku From Java to Ruby (Pragmatic Programmer). Asyik nih buku..
Bab 4: Cara propaganda Ruby:
4.a Pake pilot project.
4.b Pake trojan horse, bikin project kecil2an secara diam2 dulu.
4.c Race. Untuk satu problem, bikin solusi pake Ruby (saya sudah 2 kali pake
4.d Taruhan. "Gertak sambal" kalo pake Ruby bisa improve business value.
Buktikan saja kalo sambalnya bener2 pedes.
4.e Aksi penyelamatan. Gunakan Ruby saat project sudah kepepet waktu.
Bab 5. Menempis pandangan miring dan meremehkan Ruby secara dia scripting.
Bikin project yang ga "semestinya" bisa dilakukan scripting:
* Enterprise integration --> messaging, webservice
* LDAP (yang ini udah pernah gw lakuin. Gw bikin interface LDAP untuk manage
user, tapi aplikasi utamanya sendiri pake Struts. Yah gimana lagi, JNDI
terlalu ribet mbulet suket)
Banyak lagi sih samplenya, seperti persistence (ActiveRecord vs
Hibernate/iBatis) dll. Tapi menurut gw yg paling sexy ya middleware LDAP
Bab 6. Infiltrasi pelan2
6.a Migrasi (Java ke Ruby)
6.b Integrasi (Java dan Ruby)
6.c Adaptasi (JRuby, RJB, YAJB, RJNI, RJAVA)
6.d SOA. Selalu pake paradigma SOA (SOAP dan REST) dalam aplikasi Java
ataupun Ruby. Biar kedua spesies ini jadi gampang "ngobrol"nya.
On 11/30/06, Arie Kusuma Atmaja <ariekusumaatmaja@...> wrote:
> Arie Kusuma Atmaja wrote:
> > Tentang nomer 4, terutama *Rails* saja dulu penekanannya . supaya tidak
> > rancu sehingga newbie2 menyamakan ruby == rails.
> > (bahaya nanti, kalau ruby dianggep rails, analogi orang konglomerat dan
> > serba wah wah dianggap miskin)
> > ini senada dengan struggle uh perjuangannya teman2 Rails diluar sana di
> > tahun 2005-an dulu ya.. pernah baca situs orang jepang (tapi pake bahasa
> > inggris loh! bukan jepang) judulnya answer to those who are still
> > sceptical about rails.. trus sama satunya lagi yang ada gambar
> > kartun2nya itu dimana ya... sudah lama banget soalnya. ummmm.. ada juga
> > arsip milis rails yang baagus banget untuk menjawab nomer 4 ini, kalo
> > nggak salah bahkan sampai ditaroh di wikinya rails karna banyak
> > dijadikan rujukan buat mereka mereka yang banyak pada sukses bermigrasi
> > ke rails di luar negri sana.
> pas terlihat direktori simpenan saya liat harta karun ini saya copy
> paste kesini saja soalnya lupa dulu thread ini yg di direct link yg mana
> dan ini bukan yang ada gambar kartunnya itu. maap, cuman satu pak dan
> cuma rails. / tapi mnurut saya kalo utk ruby sih kalo geek sudah gak
> akan ragu-ragu lagi.
> Sounds like you were in exactly the same position as I was with our
> first Rails app. In my situation our boss asked what we could use to
> replace VB and MS Access applications that were going the way of the
> Dodo Bird soon. In my case it wasn't that hard of a sell since I
> proposed we spend one month doing a pilot project to see how much we
> could get done. Turned out we did the entire project's functionality in
> about 2.5 weeks so it turned into a big win for us.
> The general strategy I proposed to the head honchos is that we use Rails
> for small quick agile applications with a small number of users and then
> leave the established Java stuff to the big applications. This is a
> total farce though as Rails can handle all the same stuff if not more
> than Java (and I've proven this time and again with consistent
> statistically based performance metrics).
> The big things I can recommend you hit in your presentation are the
> 1. Seriously propose a range of alternatives--including continuing with
> the current platform--and present the pros/cons of each. They can smell
> when you're "stuffing the ballot" so be honest. For example, have you
> considered just pointing Brio, Cognos, or similar tool at your data?
> 2. Plan to handle the following questions:
> * "What about security?"
> * "How well does it scale?"
> * "What's the performance (see below) like?"
> * "How many users can it handle?"
> * "How would we deploy it?"
> * "Do we have the hardware to support it?"
> * "How does it fit into our current deployment setup?"
> * "What happens if we have to reboot the server?"
> * "Is it robust enough to handle our complex business needs?"
> 3. Give some anecdotes from other sources about the efficiency of Ruby
> on Rails, and also present the alternative rebutals from similar sources.
> 4. Demonstrate the #1 thing that Rails has over nearly every other
> framework: Native Ajax support. I'd take the time to whip up a simple
> "Ajax Demo" that showed off the cool stuff you can do with Ajax. Other
> platform advocates will have a hard time competing with that, especially
> if you show how most Ajax in Rails involves about 10 lines of code (if
> 5. If you're not good at making cheeze charts (powerpoint to biz people)
> then get ahold of a friend from marketing to help you out. Buy him/her
> lunch and they'll probably kick in some assistance. Especially if they
> can put their name on the proposal and win some cool points. Just be
> careful they don't stab you in the back and try to take credit for the
> idea (depends on where you work).
> Finally, here's some common answers to the questions I gave above:
> * "What about security?" -- Rails, being a web application framework is
> just as secure as every other framework. It provides all the normal
> features for AAA (Authentication, Authorization, Auditing) such as LDAP,
> logging, etc. and has the same weaknesses if used by uneducated
> developers. (It helps if you can find a piece of previously written
> vulnerable or bad code from the other frameworks).
> * "How well does it scale?" -- First, get them to define scalability.
> If they say, "You know, how many users can it handle?" Then be prepared
> to educate them that scalability is about being able to start small, and
> expand later, not about how many users a given system can handle.
> *That* is performance. Once you've nailed that down, tell them Rails
> adopts the "share nothing" idea so you can easily scale it out by adding
> more hardware and running more Rails. This is in contrast to complex
> Java App server deployments which require MQ systems, NFS, complex
> session shuffling, and lots of software just to scale.
> * "What's the performance like?" -- Tell them it performs just about
> the same as other platforms, sometimes better, sometimes worse. The
> advantage that Rails has over many other architectures is that it's
> simplicity makes it easier to tune and (drumroll) scale to meet
> performance needs. In addition, say that if they can come up with solid
> performance requirements, then it'll be possible to kill the project
> early if Rails can't meet the needs. The nice thing about this last
> strategy is that they are now on the hook to develop a set of metrics
> which you can then verify against existing systems.
> For example, they say, "It needs to handle 500 connections/second."
> Don't let them say "users", "users" means nothing. Then you go test
> their current WizBangOMatic and find it only handles 10 conn/second.
> You can then come to them and say that Rails can't do 500 conn/second,
> but it can do better than the WizBangOMatic which only has 10
> conn/second performance. It's evil, but it puts the performance harpies
> at rest.
> * "How many users can it handle?" -- See performance. In addition,
> "users" is a very vague term you can't measure. You can measure
> requests, connections, bytes transfered, simultaneous connected clients,
> but not users.
> * "How would we deploy it?" -- Explain the software needed, platforms it
> runs on, how well it runs on them, etc.
> * "Do we have the hardware to support it?" -- Yes, it runs on nearly
> everything, and more than Java.
> * "How does it fit into our current deployment setup?" -- This one is up
> to you. Figure it out because they'll ask.
> * "What happens if we have to reboot the server?" -- Reboot it. You can
> configure Rails to start up on reboot just like any other piece of
> software on the planet.
> * "Is it robust enough to handle our complex business needs?" -- Explain
> that several businesses are basing their lives on Rails, and that it
> seems to be as robust as every other software system.
> Good luck.
> On Sun, 21 Aug 2005 20:53:17 +0200
> Nicolas Buet <nicolas.buet@... <nicolas.buet%40gmail.com>> wrote:
> >> Hi,
> >> I understand that this might be off topic, but it's still rails
> related. I
> >> have a meeting tomorrow with a manager about a database front end
> >> He want to use jdbc, but for a change I would like to use rails.
> What do you
> >> think could convince him that Rails is a viable choice?
> >> (I don't know much about the project, but it is small: 5 weeks from
> >> to delivery, 3 users or less, no authentification... this will
> replace a "ms
> >> access" tool)
> >> Regards,
> >> Nicolas
> Rails mailing list
> Rails@... <Rails%40lists.rubyonrails.org>
> Arie Kusuma Atmaja A.K.A Arie A.K.A ariekeren / YM! = riyari3
> http://groups-beta.google.com/group/id-jp # ayo praktek ngomong jepang!
> http://groups-beta.google.com/group/id-fr # ayo praktek ngomong prancis!
[Non-text portions of this message have been removed]