Tahun 2003: Ketika Mahasiswa Lugu Bertemu Monster Bernama J2EE

Ilustrasi mahasiswa tahun 2003 membuka tutorial J2EE
dengan monitor CRT, meja berantakan, buku Java.

Bayangkan begini.

Seorang mahasiswa semester lima, baru saja lulus mata kuliah Pemrograman Java dengan nilai lumayan.

Program HelloWorld.java sudah khatam.

Bikin kalkulator sederhana pakai Swing juga sudah pernah.

Dengan modal rasa percaya diri yang, seperti biasa, sedikit lebih besar daripada pengalaman sebenarnya, ia membuka browser, mengetik:

"belajar Java Web Programming"

di Google.

Lalu ia mengklik hasil pencarian pertama.

Detik itu juga, hidupnya berubah.

Yang muncul di layar bukan tutorial ramah pemula.

Yang muncul adalah sebuah dunia bernama:

J2EE — Java 2 Platform, Enterprise Edition.

Lengkap dengan diagram arsitektur berlapis-lapis, akronim yang berbaris seperti pasukan, XML di mana-mana, dan istilah-istilah yang seolah sengaja dirancang untuk membuat orang minder duluan sebelum sempat menulis baris kode pertama.

Coba bayangkan raut wajahnya.

Ini bukan lagi wajah excited seperti ketika berhasil mencetak:

Hello, World!

ke layar.

Ini wajah seorang anak muda yang baru sadar:

"Kayaknya saya salah masuk ruangan."

Minggu Pertama: Perkenalan yang Tidak Ramah

Kolase istilah Java Web awal 2000-an: Servlet, JSP, XML, WAR, Tomcat.

Hal pertama yang ia temukan adalah bahwa "belajar web pakai Java" ternyata bukan cuma soal Java.

Ada satu ekosistem lengkap yang harus dipahami.

Dan masalahnya, setiap istilah seperti membuka pintu ke tiga istilah baru.

Servlet

Katanya ini adalah cara Java menangani HTTP request.

Oke.

Masih masuk akal.

Tapi kenapa harus extends HttpServlet?

Kenapa harus override doGet() dan doPost()?

Kenapa harus membuat web.xml?

Kenapa ada WAR?

Kenapa ada container?

Kenapa ada Tomcat?

Baru saja mulai tenang, muncul istilah berikutnya.

JSP — JavaServer Pages

"Ini lebih gampang," kata sebuah tutorial.

Ternyata JSP adalah HTML yang disisipi kode Java:

<%= user.getName() %>

Kemudian diberitahu bahwa JSP nantinya diproses menjadi Servlet.

Mahasiswa kita mulai bertanya:

"Jadi... sebenarnya saya sedang menulis Servlet atau HTML?"

Tidak ada yang menjawab dengan cukup sederhana.

Kemudian Muncul Tiga Server yang Namanya Mirip-Mirip

Ilustrasi lucu: Apache, Tomcat, WebLogic, WebSphere, JBoss, GlassFish mengelilingi mahasiswa yang kebingungan.

Ini bagian yang benar-benar membuat pemula mulai mempertanyakan pilihan hidup.

Ia membaca:

Web Server.

Kemudian menemukan:

Web Container.

Kemudian:

Application Server.

Dan semuanya disebut "server".

Lalu muncul nama:

Apache Tomcat WebLogic WebSphere JBoss GlassFish

Mahasiswa kita mulai mencatat.

Tapi lima menit kemudian catatannya sudah seperti ini:

Apache = server Tomcat = server WebLogic = server JBoss = server GlassFish = server

Yang tentu saja tidak membantu sama sekali.

Jadi mari kita berhenti sebentar.

Karena sebenarnya ada perbedaan penting.

Web Server Itu Apa?

Diagram sederhana Browser → Web Server → HTTP Response.

Web server berada di dunia HTTP.

Contohnya:

Apache HTTP Server
NGINX
Microsoft IIS

Tugas utamanya adalah menerima HTTP request dan memberikan HTTP response.

Browser | | GET /index.html v Web Server | | HTML v Browser

Kalau yang diminta adalah file statis:

index.html style.css logo.png

web server sudah sangat cukup.

Tapi sekarang muncul masalah:

Bagaimana kalau request tersebut harus menjalankan program Java?

Misalnya:

GET /customer/123

dan server harus menjalankan business logic untuk mengambil customer nomor 123 dari database.

Apache HTTP Server tidak otomatis tahu bagaimana menjalankan Servlet.

Maka kita membutuhkan lapisan lain.

Web Container

Diagram Browser → Tomcat → Servlet → Java Application.

Di dunia Java Web muncul istilah:

Web Container atau Servlet Container.

Contoh yang sangat terkenal:

Apache Tomcat.

Secara sederhana, Tomcat menyediakan runtime untuk menjalankan aplikasi web berbasis Servlet dan teknologi web Java terkait.

Browser | | HTTP v Tomcat | v Servlet | v Java Application

Tomcat bukan sekadar "web server Java".

Ia memahami konsep seperti:

Servlet JSP Servlet lifecycle HTTP request HTTP response Web application

Dan di sinilah mahasiswa kita mulai menemukan satu pola yang sebenarnya akan terus muncul dalam dunia Java:

Ada kontrak/aturan, lalu ada software yang mengimplementasikan kontrak tersebut.

CATATAN PENTING:
Untuk sekarang, cukup simpan satu kalimat: Specification menjelaskan kontraknya. Implementation menjalankan kontrak tersebut. Nanti kita akan bertemu pola yang sama berkali-kali.

Lalu Apa Bedanya dengan Application Server?

Diagram Web Server vs Web Container vs Application Server.

Kalau Tomcat menyediakan web container, application server berada pada cakupan yang lebih besar.

Enterprise Java tidak hanya membutuhkan HTTP.

Sistem enterprise juga membutuhkan:

Transaction Security Messaging Naming Connection Pooling EJB Resource Management Clustering dan berbagai layanan enterprise lainnya

Maka application server menyediakan runtime yang lebih lengkap.

Web Server

Fokus:

HTTP Static Content Proxy Routing

Contoh:

Apache HTTP Server NGINX IIS

Web Container

Fokus:

Servlet JSP Java Web Application

Contoh:

Tomcat

Application Server

Fokus:

Web + Enterprise Services

Contoh pada era J2EE:

WebLogic WebSphere JBoss GlassFish

Jadi:

Apache HTTP Server ≠ Tomcat ≠ WebLogic

Mereka berada pada lapisan yang berbeda, walaupun semuanya sama-sama disebut "server".

Jadi Apakah Tomcat Bisa Berdiri Sendiri?

Bisa.

Browser | v Tomcat | v Java Web Application | v Database

Tetapi perusahaan bisa menambahkan web server atau reverse proxy di depan:

Internet | v NGINX / Apache | v Tomcat | v Java Application

Dan untuk enterprise application yang membutuhkan berbagai layanan Java EE:

Sekarang mahasiswa kita mulai melihat bentuk dunia Java Web.

Tapi ternyata itu baru permukaan.

Minggu Kedua: Sang Monster Sesungguhnya — EJB

Ilustrasi EJB 2.x sebagai "boss monster" dengan Home Interface, Remote Interface, Bean Class dan XML.

Kalau Servlet dan JSP tadi baru pemanasan, maka Enterprise JavaBeans (EJB) adalah level boss yang sesungguhnya.

Untuk membuat komponen bisnis sederhana di dunia EJB 2.x, mahasiswa kita bisa berhadapan dengan:

Home Interface
Remote Interface atau Local Interface
Bean Class
Deployment Descriptor

Sebuah business component sederhana saja bisa menghasilkan beberapa artefak.

Belum lagi lifecycle callback seperti:

ejbCreate() ejbRemove() ejbActivate() ejbPassivate()

Mahasiswa kita melihat kode tersebut dan berpikir:

"Saya cuma mau bikin Account yang punya deposit() dan withdraw()."

Tetapi dunia menjawab:

"Tenang. Kita belum selesai."

Kalau dia nekat masuk ke Entity Bean, ia menemukan:

CMP BMP Persistence Container Relationships Deployment Descriptor

dan sekarang XML yang tadi terasa menyebalkan mulai terlihat seperti masalah kecil.

Kenapa Harus Ada Interface dan Banyak Pemisahan?

Ilustrasi abstraction: contract di satu sisi, implementation di sisi lain.

Di sinilah kita beri mahasiswa kita sedikit bekal.

Tidak perlu kuliah OOP dulu.

Cukup pahami satu ide:

Java sangat kuat menggunakan abstraction, yaitu memisahkan "apa yang harus dilakukan" dari "bagaimana cara melakukannya".

Misalnya secara sederhana:

Contract ↓ "Account harus bisa deposit dan withdraw" ↓ Implementation ↓ "Bagaimana deposit dan withdraw itu benar-benar dilakukan"

Konsep seperti ini penting dalam Java karena memungkinkan komponen tidak harus terlalu mengetahui detail implementasi komponen lain.

Dan pola ini ternyata tidak berhenti di OOP.

Ia akan muncul lagi pada level yang jauh lebih besar.

Specification vs Implementation

Diagram J2EE Specification → WebLogic / GlassFish / WebSphere / JBoss.

Nah, ini salah satu kunci untuk memahami dunia Java Enterprise.

Mahasiswa kita mulai bertanya:

"Kenapa ada J2EE, tapi juga ada WebLogic?"

"Kenapa ada GlassFish?"

"Kenapa ada WebSphere?"

"Kenapa ada JBoss?"

Bukankah semuanya Java?

Jawabannya:

Tidak semuanya berada pada level yang sama.

J2EE adalah platform dan kumpulan specification.

Specification pada dasarnya mendefinisikan kontrak:

"Teknologi enterprise Java ini harus menyediakan kemampuan tertentu dan memiliki perilaku tertentu."

Kemudian vendor atau proyek tertentu membuat implementation yang menjalankan kontrak tersebut.

Mereka bukan "Java yang berbeda".

Mereka adalah implementasi/platform runtime dari specification Java enterprise dengan karakteristik dan fitur vendor masing-masing.

Analogi Sederhananya

Bayangkan ada aturan:

Sebuah kendaraan harus memenuhi standar tertentu agar boleh digunakan di jalan.

Produsen berbeda bisa membuat:

Toyota Honda BMW Mercedes

Mobilnya berbeda.

Mesinnya berbeda.

Teknologinya berbeda.

Tetapi semuanya harus memenuhi aturan yang berlaku.

Kurang lebih begitulah hubungan:

Specification | +-- Rules / Contract | `-- Implementation

Jadi:

J2EE bukan WebLogic.

J2EE bukan GlassFish.

J2EE bukan WebSphere.

J2EE adalah specification/platform.

WebLogic, GlassFish, WebSphere, JBoss dan lainnya adalah implementasi/platform runtime yang menyediakan teknologi enterprise tersebut.

Dan Ini Bukan Hanya Terjadi pada J2EE

Diagram specification/implementation berulang di Servlet, JPA dan JDK.

Ini yang menarik.

Pola yang sama akan terus muncul di dunia Java.

JPA | +-- Hibernate | +-- EclipseLink

JPA mendefinisikan persistence API dan contract.

Hibernate dan EclipseLink menyediakan implementation.

Begitu pula:

Servlet | +-- Tomcat +-- Jetty +-- Undertow

Dan bahkan pada level JDK, mahasiswa modern bisa menemukan:

OpenJDK Oracle JDK Amazon Corretto Microsoft Build of OpenJDK Eclipse Temurin dan lainnya

Pemula mungkin melihat:

"Kok Java banyak sekali?"

Padahal mental modelnya sederhana:

Standard / Specification ↓ Implementation / Distribution

Konsep ini adalah salah satu alasan kenapa Java ecosystem bisa memiliki banyak vendor dan implementasi tanpa harus menjadi banyak bahasa pemrograman yang berbeda.

Tapi jangan terlalu lama membahas ini.

Mahasiswa kita masih harus selamat dari EJB.

Kembali ke EJB

Sekarang ia mulai memahami bahwa EJB bukan sekadar class Java biasa.

EJB hidup di dalam EJB Container.

Container tersebut menyediakan berbagai layanan enterprise.

Transaction Security Lifecycle Pooling Concurrency Naming

Jadi ketika developer menulis EJB, sebenarnya ia tidak sedang membuat seluruh infrastructure dari nol.

Container yang mengerjakan banyak hal.

Application | +-- EJB | v EJB Container | +-- Transaction +-- Security +-- Lifecycle +-- Resource Management

Masalahnya:

untuk mendapatkan semua kekuatan tersebut, harga yang dibayar developer saat itu cukup mahal dalam hal kompleksitas.

Dan XML Ada Di Mana-Mana

Screenshot/ilustrasi XML deployment descriptor bergaya editor tahun 2000-an.

Kalau hari ini developer terbiasa dengan:

@RestController @Service @Repository

developer Java awal 2000-an sangat akrab dengan:

web.xml ejb-jar.xml application.xml

Konfigurasi deployment bisa menjadi bagian besar dari pekerjaan.

Aplikasi bukan hanya:

Java Code

tetapi:

Java Code + XML + JAR + WAR + EAR + Application Server Configuration

Mahasiswa kita mulai memahami bahwa coding ternyata hanya sebagian dari pekerjaan.

Sisanya?

Meyakinkan server bahwa semua yang kita tulis memang pantas dijalankan.

Bagaimana Java Web Dulu Di-deploy?

Ilustrasi WAR/EAR di-deploy ke application server.

Ini juga berbeda jauh dengan zaman Spring Boot.

Sekarang kita bisa melakukan:

java -jar application.jar

Pada masa itu, aplikasi web Java umumnya dikemas sebagai:

WAR — Web Application Archive.

Strukturnya kira-kira:

myapp.war │ ├── index.jsp │ ├── WEB-INF/ │ ├── web.xml │ │ │ ├── classes/ │ │ └── com/example/MyServlet.class │ │ │ └── lib/ │ ├── library1.jar │ └── library2.jar │ └── images/

Kemudian WAR tersebut di-deploy ke Servlet Container atau Application Server.

myapp.war | v Application Server | v Deploy | v http://server/myapp

Kalau aplikasi menggunakan komponen enterprise seperti EJB, packaging-nya bisa melibatkan:

EAR — Enterprise Archive.

myapp.ear │ ├── web.war ├── business.jar └── META-INF/ └── application.xml

Jadi:

WAR ↓ Web Application EAR ↓ Enterprise Application ↓ WAR + EJB / enterprise modules

Dan semuanya harus cocok dengan application server.

Inilah Saat Classpath Menjadi Musuh

Screenshot stack trace klasik: ClassNotFoundException / NoClassDefFoundError.

Mahasiswa kita sudah berhasil membuat aplikasi.

Compile berhasil.

WAR berhasil.

Dia tersenyum.

Kemudian deploy.

ClassNotFoundException

Dia memperbaiki dependency.

Deploy lagi.

NoClassDefFoundError

Dia mulai membuka:

WEB-INF/lib

Kemudian classpath application server.

Kemudian library vendor.

Kemudian deployment descriptor.

Kemudian membaca dokumentasi.

Kemudian membuka forum.

Kalau beruntung, seseorang menjawab dua atau tiga hari kemudian.

Kalau tidak:

"Coba reinstall application server."

Sebuah solusi universal yang sudah dikenal umat manusia sejak zaman dahulu.

:-)

Minggu Ketiga: Mahasiswa Mulai Mengenal Nama-Nama Besar

Poster/kolase logo lama Tomcat, WebLogic, WebSphere, JBoss dan GlassFish.

Sekarang ia mulai melihat:

Tomcat WebLogic WebSphere JBoss GlassFish

Dan akhirnya mulai memahami:

Apache HTTP Server | `-- Web Server Tomcat | `-- Servlet / Web Container WebLogic / WebSphere / JBoss / GlassFish | `-- Application Server / Java EE Runtime

Dan di atasnya ada:

J2EE | `-- Specification / Platform

Sedangkan di bawahnya:

Database

dan mungkin:

JDBC

untuk mengakses database.

Untuk pertama kalinya diagram itu mulai masuk akal.

Tapi Kenapa Semua Ini Harus Ada?

Ilustrasi bank/telekomunikasi/pemerintahan dengan tumpukan enterprise services.

Nah, sekarang kita bisa melihat alasan sebenarnya.

J2EE tidak dibuat untuk membuat:

"Website daftar nama mahasiswa."

J2EE dirancang untuk kebutuhan enterprise.

Bayangkan:

Bank Telekomunikasi Pemerintahan Insurance Enterprise ERP

Sistem seperti itu membutuhkan:

Transaction Security Messaging Concurrency Distributed Processing Connection Pooling Clustering High Availability Resource Management

Kalau setiap developer harus membuat semua infrastructure tersebut sendiri, pekerjaannya akan jauh lebih berat.

Maka application server menyediakan infrastructure tersebut.

Business Application | v Enterprise Container | +-- Transaction +-- Security +-- Messaging +-- Naming +-- Resource Management | v Infrastructure

Jadi kompleksitas itu bukan muncul tanpa alasan.

Masalahnya adalah:

mahasiswa yang baru belajar web harus mempelajari infrastructure yang sebenarnya dirancang untuk kebutuhan enterprise.

Ibarat baru belajar naik sepeda, tetapi manual yang diberikan adalah manual pengoperasian Boeing.

Wajah Mahasiswa Kita di Akhir Minggu Pertama

Ilustrasi mahasiswa di depan CRT, ekspresi kosong, kopi, buku, XML dan stack trace.

Bukan wajah marah.

Lebih seperti:

kosong.

Mata sedikit sayu karena begadang.

Di layar:

web.xml ejb-jar.xml application.xml

Di sebelahnya:

Tomcat WebLogic J2EE EJB JNDI JTA JMS JDBC

Di kepalanya:

"Kemarin saya baru belajar inheritance."

Kemudian muncul pikiran yang lebih dalam:

"Apakah hidup memang seperti ini?"

Belum.

Dia belum tahu bahwa beberapa tahun kemudian dunia akan memperkenalkan:

Spring Hibernate Maven REST JSON Microservices Docker Kubernetes

Dan semuanya akan membuat dia kembali mempertanyakan keputusan hidupnya.

Tapi itu cerita lain.

Lalu Datanglah Spring

Ilustrasi transisi dari monster EJB menuju Spring yang lebih ringan.

Sekitar era yang sama, muncul sebuah pendekatan yang mencoba menjawab kegelisahan developer terhadap kompleksitas enterprise Java.

Spring Framework.

Salah satu ide pentingnya adalah membuat pengembangan enterprise lebih ringan dengan memanfaatkan Java object biasa, dependency injection, dan inversion of control.

Daripada developer terlalu erat bergantung kepada infrastructure container, Spring berusaha membuat infrastructure tersebut bekerja di belakang layar.

DULU Application | +-- Enterprise Container | +-- Business Component KEMUDIAN Application | +-- Spring Container | +-- POJO / Business Object

Dan perlahan-lahan dunia Java berubah.

Dari J2EE ke Spring Boot

Hari ini kita bisa menulis:

@RestController @Service @Repository

lalu:

java -jar application.jar

Selesai.

Tidak perlu memikirkan deployment descriptor sebanyak generasi sebelumnya.

Tidak perlu memahami seluruh application server hanya untuk membuat endpoint sederhana.

Tidak perlu mengetahui seluruh isi mesin sebelum aplikasi bisa dijalankan.

Tetapi jangan salah.

Kompleksitasnya tidak benar-benar hilang.

Ia diabstraksikan.

Itulah salah satu fungsi abstraction.

Developer modern berdiri di atas puluhan tahun hasil kerja generasi sebelumnya.

Dan Ini Mungkin Pelajaran Terpenting dari Semua Kekacauan Ini

Diagram besar: Abstraction → Specification/Contract → Implementation → Container/Runtime → Application.

Kalau suatu hari kamu belajar Java dan menemukan:

Interface API Specification Implementation Container Framework Runtime

jangan langsung menghafal semuanya.

Coba tanyakan:

"Ini berada di level mana?"

Dan:

"Apakah ini specification atau implementation?"

Karena pola yang sama muncul berkali-kali.

Java API | v Implementation

JPA | +-- Hibernate | +-- EclipseLink

Servlet | +-- Tomcat +-- Jetty +-- Undertow

J2EE / Java EE | +-- WebLogic +-- GlassFish +-- WebSphere +-- JBoss

Bahkan:

Java Platform | +-- Oracle JDK +-- Amazon Corretto +-- Microsoft OpenJDK +-- Eclipse Temurin +-- Others

Java ternyata tidak sesederhana:

"Install Java, lalu coding."

Java adalah ecosystem yang dibangun sangat kuat di atas abstraction, specification, implementation, dan containerization.

Tetapi untuk mahasiswa tahun 2003, tentu saja semua penjelasan filosofis itu belum terasa.

Yang dia tahu cuma satu:

"Kenapa bikin login saja harus begini?"

Penutup

Ilustrasi mahasiswa 2003 berubah menjadi developer senior, dengan timeline Java Web di belakangnya.

Setiap generasi developer punya monster mereka sendiri.

Generasi 2003 punya:

J2EE EJB XML Application Server Deployment Descriptor WAR EAR Classpath

Generasi berikutnya mendapat:

Spring Hibernate Maven REST

Generasi sekarang mendapat:

Microservices Docker Kubernetes Cloud Distributed Systems

Teknologinya berubah.

Monster-nya berganti.

Tetapi pengalaman menjadi mahasiswa atau developer muda yang pertama kali berhadapan dengan dunia enterprise hampir selalu sama:

"Kok ternyata banyak banget yang harus saya pahami?"

Dan mungkin itu bukan tanda bahwa kita tidak mampu.

Mungkin memang begitulah cara seseorang mulai memahami dunia software engineering.

Awalnya kita melihat:

Servlet JSP EJB JPA Tomcat WebLogic Hibernate Spring

sebagai kumpulan nama yang tidak berhubungan.

Kemudian perlahan kita belajar melihat:

Abstraction | v Specification / Contract | v Implementation | v Container / Runtime | v Application

Dan ketika pola itu mulai terlihat, sesuatu yang tadinya terasa seperti hutan mulai berubah menjadi peta.

Itulah titik ketika Java mulai terasa masuk akal.

Bukan karena Java menjadi lebih sederhana.
Tetapi karena kita akhirnya tahu bagaimana membacanya.

☕ JAVA WEB ARCHIVE // 2003

Oh, dan satu lagi...

Di tengah pembicaraan tentang J2EE, EJB, Spring, Tomcat dan segala monster enterprise tadi, ada satu framework yang mungkin sejak tadi berdiri di pojokan sambil mengangkat tangan.

"Ehem..."

"Kenapa aku nggak dibahas?"

Mahasiswa kita menoleh.

Namanya:

Play Framework

Mahasiswa kita mengernyit.

"Play siapa?"

Play Framework terdiam.

Kemudian perlahan menatap kamera.

"Am I a joke to you?"

😂

Tenang, Play.

Kamu bukan anak haram.

Kamu cuma sering menjadi anak yang terlupakan ketika orang membicarakan Java Web.

Play Framework memang punya tempat sendiri dalam ekosistem JVM. Ia adalah web framework, bukan application server seperti WebLogic atau GlassFish, dan bukan implementation dari J2EE.

Pendekatannya juga berbeda dari model Java EE klasik maupun Spring MVC. Play hadir sebagai alternatif untuk membangun aplikasi web di atas JVM dengan programming model-nya sendiri.

Jadi kalau kita masukkan ke peta besar Java Web:

Play bukan "Java EE versi lain".

Ia adalah jalur alternatif dalam dunia web development di JVM.

Dan meskipun Play pernah menjadi pilihan yang menarik bagi developer yang menginginkan pendekatan web yang berbeda dari enterprise Java tradisional, dalam perjalanan Java enterprise mainstream, Spring akhirnya menjadi jauh lebih dominan.

Akibatnya, ketika orang membicarakan evolusi Java Web, nama Play sering berada di pinggir cerita.

Bukan karena Play tidak ada.

Bukan karena Play tidak legitimate.

Dia cuma...

datang ke reuni Java ketika semua orang sudah sibuk ngobrol tentang Spring Boot.

"Am I a joke to you?"

😂

Tidak, Play.

Tapi kamu memang jarang diajak reuni.

☕

Dan mungkin justru itu menjadi penutup yang bagus untuk memahami Java Web.

Ekosistem Java tidak pernah hanya memiliki satu jalan.

Specification Implementation Container Application Server Framework Library Runtime

Masing-masing berada pada lapisan dan menyelesaikan problem yang berbeda.

Kalau kita memahami lapisan-lapisan tersebut, nama-nama seperti J2EE, WebLogic, Tomcat, Hibernate, Spring, bahkan Play Framework tidak lagi terlihat seperti sekumpulan teknologi random.

Mereka mulai terlihat sebagai bagian-bagian dari sebuah ekosistem yang berevolusi selama puluhan tahun.

Dan di suatu sudut dunia JVM, Play Framework masih berdiri sambil berkata:

"Saya juga pernah ada, lho..." 😄

[ End of transmission... ]

Search This Blog

Just another programmer's diary