Archive for Java
06.30.08
Posted in Java at 2:07 am by rast
scalability - pe limba lui Shakespeare.
Conform glosarului de termeni tehnici, de aici, scalabititatea este: “însuşirea unui sistem, echipament, dispozitiv etc. de a permite schimbări importante ale dimensiunilor şi/sau capacităţii sale, cu costuri acceptabile, fără dificultăţi şi cu păstrarea caracteristicilor şi performanţelor iniţiale”.
Un program/aplicaţie software este “un sistem” care se supune acestei legi a scalabilităţii. Din păcate, sunt puţine programe care să fie scalabile. M-am confruntat direct cu această problemă, în diverse împrejurări, axând diferite “poziţii” faţă de softul respectiv.
Applet-ul de la DRDP, care avea peste 6000 de linii, nu a pornit de la un proiect global. Am început o aplicaţie cu un scop bine precizat, dar mică, apoi am adăugat diverse facilităţi, înglobând una câte una, tabelele din baza de date.
Acel program de PLUP (Pregătirea, Lansarea şi Urmărirea Producţiei) realizat într-un job part-time, în vreo 2-3 ani, a avut cam aceeaşi “soartă”, am adăugat fel de fel de facilităţi, “deranjând”, funcţionalităţile anterioare. Programul a fost înlocuit cu unul realizat de o firmă care are exact aceeaşi… “soartă”. Nici acum nu este gata. Se adaugă câte ceva (capabilităţi) şi apar probleme în 3-4 alte locuri care funcţionau corect înainte. Deci… se întâmplă şi la case mai mari.
În aplicaţia la care lucrez în prezent am încercat să ocolesc această problemă, proiectând din start aplicaţia la un caz cât mai general posibil, particularizând-o pentru diverşii clienţi, prin setări într-un fişier extern… care este “citit” de aplicaţie în momentul start-ării ei. M-am confruntat chiar săptămâna trecută cu un client cu o anumită cerinţă particulară şi nu a fost cazul de modificări a programului. Cerinţa a fost indeplinită doar prin setări din acel fişier extern.
Mă captivează foarte mult această problemă a modularizării şi scalabilităţii. “Mă apasă” 
tot mai tare un gând: să încep să fac nişte componente/clase (ceva Beans, EJB) îmbinabile între ele, cu o rezultantă clară: aplicaţia, aşa cum o vrea clientul. Cea mai generală soluţie ar fi proiectarea ei într-un soft de modelare UML, independent de limbajul de programare folosit, apoi implementarea soluţiei în diverse limbaje de programare: Java, PHP…
Poate ar trebui să ţin cont şi de expansiunea AJAX, care se vede foarte pregnant în versiunea 2.5.1 a WordPress-ului.
Permalink
06.24.08
Posted in Java at 1:44 am by rast
Orice aplicaţie Java, din fişiere *.java, trebuie “supusă” unui proces de compilare şi transformată în fişiere *.class, pentru a putea fi interpretate de JVM. Orice compilator semnalează două tipuri de… “greşeli de programare”.
Aplicaţia nu este compilată dacă apar error(s). Cu warning(s)… merge! Warnings sunt atenţionări… că ceva nu este în regulă! Am tot folosit pentru compilare, compilatorul care este “livrat” cu SDK-ul de la SUN. Ei fiind “părintele” Java, mi se pare logic, ca produsele lor destinate Java, să fie cele mai bune.
Chiar aveam motive de laudă, văzând că aplicaţia mea nu dădea mesaje de warning(s). Am avut o decepţie când, după compilarea cu Eclipse, “mi s-au arătat” peste 100 de warning(s).
Unele dintre ele fiind date de variabile declarate şi ne-utilizate care, practic, încarcă oarecum inutil aplicaţia. Iar altele, date de variabile declarate statice şi apelate în alte clase de metode ne-statice.
Cei ce dezvoltă Eclipse au sesizat astfel de “scăpări” ale programatorilor OO (Object-Oriented), dar cei de la SUN… dorm?
Nu pot să înţeleg un lucru: de ce, în această epocă concurenţială, unii “se lasă pe tânjală”? Cele două tipuri de worning(s) nu sunt “invenţii” ale celor de la Eclipse, sunt chestii… “de bun simţ”. SUN nu ar putea fi condamnat că a copiat ideea Eclipse, de a semnala cele două worning(s). De ce nu o fac? De ce îşi lasă compilatorul incomplet?
Permalink
06.23.08
Posted in Java at 12:08 am by rast
Programele, Java sau PHP, le scriam în Notepad. Nu am fost niciodată interesat să învăţ un framework sau un IDE. Interesul era chiar unul evident pentru Notepad. Chiar dacă este mai greoi, te “obligă” să ai cunoştinţe mai aprofundate ale limbajului folosit.
Azi am download-at şi făcut o mică probă pentru Eclipse. Deja, programul de raportare, la care lucrez, depăşeşte 7500 de linii şi este foarte greu de urmărit în Notepad.
De la prima vedere mi-a plăcut Eclipse-ul , prin facilitatea, cunoscută mie de la Notepad++, de a putea restrânge codul unei metode sau clase.
Am ajuns la ideea de a folosi Eclipse-ul şi datorită unor lecturi de-ale mele din ultima perioadă, despre uneltele UML. Am şi o experienţă personală, într-o proastă gestionare a claselor ce compun un program vast, dar mă şi “confrunt” deseori cu astfel de probleme, prin povestirile ce mi le împărtăşeşte un coleg ce utilizează un program al unei firme. Program ce are mari probleme, scris în C#.
Interesant ar fi nu numai un program UML, ce permite proiectarea programelor, ci un program ce analizează deja o aplicaţie existentă şi “semnalează” incoerenţe ale utilizării metodelor şi variabilelor folosite în diverse clase componente. Se pare că Eclipse-ul are nişte plugin-uri ce oferă proiectare UML.
Oricum, la cele peste 7000 de linii ale programului de raportare, pot “testa” multe capabilităţi ale Eclipse-ului.
Permalink
06.12.08
Posted in Java at 3:10 am by rast
M-am gândit multă vreme dacă să includ şi J2ME în discuţie. Voi spune doar câteva cuvinte: este un pachet “minimal” din J2SE destinat aplicaţiilor de pe dispozitive mobile, deci nu calculatoare şi implicit Internet.
J2SE - Java 2 Standard Edition - conţine clasele Java de bază pentru a dezvolta aplicaţii standalone şi applet-uri. Se pot dezvolta aplicaţii Swing, ce pot rula, accesând diverse resurse (baze de date) situate pe orice server web. Condiţia esenţială fiind ca pe calculatorul client să fie instalată o JVM a unei versiuni superioare cu cea cu care a fost compilată aplicaţia Swing.
J2EE - Java 2 Enterprise Edition - este “o extensie” a J2EE. Pe lângă applet-uri şi aplicaţii standalone se pot dezvolta şi aplicaţii web, aplicaţii care “trimit” vizitatorului (calculatorului client) o pagină .html, generată dinamic de aplicaţia J2EE.
Care ar fi diferenţa dintre cele două tipuri de aplicaţii:
- applet-uri şi standalone
- aplicaţii web
Primele, în momentul în care vizitatorul “o accesează”, este integral “transportată” prin Internet, pe calculatorul client, vizitatorul optând pentru funcţionalităţile disponibile.
Celelalte, aplicaţiile web, nu sunt încărcate “din prima” pe calculatorul client, ci sunt accesate în măsura în care vizitatorul este interesat de anumite funcţionalităţi.
Am putea considera, la o primă vedere/analiză, că aplicaţiile web reduc, într-o oarecare măsură, traficul pe Internet. Avantaj nesemnificativ faţă de uzabilitatea şi intuitivitatea unei interfeţe oferite de applet-uri sau aplicaţii standalone.
Aplicaţiile JSP au nevoie şi de un server care să comunice cu clientul. Cel mai popular este Tomcat, comunicând, implicit, pe portul 8080.
Aplicaţiile PHP sunt “gestionate” direct de serverul Apache, pe portul 80. Tomcat este dezvoltat tot de Apache. Chiar… mă macină o curiozitate. De ce JSP-urile nu sunt suportate de serverul web Apacke standard, pe portul 80? Acesta ar putea un dezavantaj JSP, faţă de PHP. Din cauza firewall-urilor. Problema depăşeşte atribuţiile unui programator , atacând responsabilităţi de administrator.
Permalink
06.03.08
Posted in Java at 3:23 am by rast
După cum se ştie, componentele Swing au un design “model-vedere” separabil. Dar, în realitate, componentele Swing, nu sunt bazate pe arhitectura Model-View-Controller (MVC).
Scopul dezvoltării pachetului de clase/componente Swing a fost: construirea unui set de Interfeţe Utilizator care să permită programatorului o dezvoltare mai rapidă a interfeţelor front-end pentru aplicaţiile comerciale.
Din acest motiv, echipa de dezvoltare a pachetului Swing, de la SUN, şi-a stabilit un set de obiective de proiectare care a dus în final la această arhitectură. Aceste “linii directoare” s-ar putea concretiza în:
- o implementare în totalitate în Java, pentru a promova o coerenţă cross-platform şi o mentenanţă (întreţinere) uşoară
- furnizarea unui singur API, capabil să suporte multiple “look-and-feels”, astfel încât programatorii şi end-userii să nu fie blocaţi într-un singur “look-and-feel”
- activarea puterii de proramare “model-driven”, fără a fi necesară în cel mai înalt nivel de API
- adăugarea lui (a pachetulu Swing) la principiile de design pentru JavaBeans, astfel încât să se certifice o comportare bună a acestor componente în IDE-uri şi alte “build tools”-uri
- furnizarea compatibilităţii cu API-ul AWT, acolo unde există suprapuneri, pentru a eficientiza AWT-ul de cunoştinţele de bază şi portabilitate uşoară.
Arhitectura Swing are rădăcini în design-ul MVC (Model-View-Controller) care datează de la limbajul SmallTalk. Arhitectura MVC, aplicată pentru o aplicaţie vizuală, se împarte în trei componente distincte:
- un model, care reprezintă datele aplicaţiei
- view (vederea), care este o reprezentare vizuală a datelor
- un controller, care să preia datele introduse de utilizator în view şi traducerea acestor modificări în model.
La început, MVC a fost o alegere logică pentru Swing deoarece asigura o bază pentru întrunirea primelor trei principii de proiectare, dar cu probleme pentru stabilirea celorlalte două.
Primul prototip Swing a urmat o arhitectură MVC tradiţională, în care fiecare componentă avea un obiect model separat şi delega implementarea “look-and-feel”-ului la obiecte diferite de view şi controller.
Practica a arătat că acest prototip nu se comporta bine deoarece partea de view şi controller a componentei necesita o strânsă interacţiune (de exemplu: este foarte dificil să scrii un controller generic fără să ştii specificaţii despre view). S-a optat deci, pentru a uni aceste două entităţi într-un singur obiect de UI (User-Interface), aşa cum se arată mai jos:
Aşa cum se ilustrează în desenul de mai sus, arhitectura Swing a “pierdut” principiile de bază, dar nu cele strict de bază, ale unui design MVC tradiţional. În lumea Swing, acest nou design: cvasi-MVC, este uneori definit ca un model separat de arhitectură.
Permalink
05.27.08
Posted in Java at 1:10 am by rast
Cele mai multe componente Swing au modele. De exemplu, un buton (JButton) are un model (un obiect ButtonModel) care stochează starea butonului - care este mnemonica lui de tastatură, dacă este activat (enabled), selectat sau apăsat, şi aşa mai departe. Unele componente au mai multe modele. De exemplu, o listă (JList) utilizează un ListModel pentru a reţine lista conţinutului şi un ListSelectionModel pentru a urmări lista selecţiilor curente.
Deseori, nu este nevoie să cunoşti nimic despre modelele pe care le utilizează o componentă. Spre exemplu, programele care utilizează butoane, fac apel direct la obiecte de tip JButton fără a face apel şi la obiecte ButtonModel.
Atunci, se pune întrebarea: de ce există modelele? Motivul principal este că ele oferă o mai mare flexibilitate în a stabili ce date sunt stocate şi/sau regăsite (returnate). De exemplu, dacă se proiectează o aplicaţie de spreadsheed (calcul tabelar) care să afişeze datele într-un tabel “slab populat”, se poate crea propriul model de tabel care să fie optimizat pentru o astfel de utilizare.
Modelele au şi alte beneficii/utilizări. Datele nu sunt copiate între un program de structuri de date şi cele ale componentelor Swing. De asemenea, modelele propagă automat modificările făcute în toate “listele de ascultare” (listeners) interesate, făcând-ul uşor pentru mediul GUI să rămână sincronizat cu datele manipulate. De exemplu, pentru a adăuga elemente într-o listă se poate apela la o metodă a modelului listei. Când se schimbă modelul datelor, modelul propagă evenimentele la JList, precum şi la alte “liste de ascultare” înregistrate, şi GUI este actualizat în consecinţă.
Deşi arhitectura modelelor Swing este uneori menţionată ca o implementare MVC (Model-View-Controller), nu este aşa. Componentele Swing sunt, în general implementate, astfel încât vederea şi controller-ul sunt indivizibile, implementate de un singur obiect UI furnizat de aspectul “look and feel”. Arhitectura modelului Swing poate fi, mai exact descrisă, ca o arhitectură cu modele separate. Pentru mai multe date despre modelul Swing, aici.
Permalink
05.23.08
Posted in Java at 3:25 am by rast
Iată codul din exemplul precedent care este utilizat pentru a obţine panoul de conţinul (content pane) pentru frame-ul creat şi adăugarea unei etichete (JLabel) colorate în galben.
frame.getContentPane().add(yellowLabel, BorderLayout.CENTER);
Aşa cum se vede din linia de cod de mai sus, panoul conţinut (content pane) al container-ului top-level, se determină apelând metoda getContentPane. “Panoul conţinut” implicit, este un simplu container intermediar, moştenit de la obiectul JComponent şi care utilizează un BorderLayout ca manager al interfeţei.
Este uşor să se particularizeze “content pane”-ul - setând layout manager-ul sau adăugând un “border”, de exemplu. Cu toate acestea, există o mică capcană. Metoda GetContentPane returnează un obiect container, nu un obiect JComponent. Aceasta însemnă că dacă se urmăreşte obţinerea unor avantaje ca “content pane” al unui obiect de tip JComponent, trebuie să se typecast (transformare de tip) valoarea returnată, sau să se creeze propria componentă care să fie panoul conţinut. În general, se preferă cea de-a două modalitate, de a crea propria componentă, fiind un pic mai curată.
De menţionat faptul că, implicit, layout manager-ul pentru JPanel este FlowLayout şi probabil se va dori modificarea lui.
Pentru a realiza o componentă a “content pane” utilizăm metoda setContentPane, a container-ului top-level. de exemplu:
//Create a panel and add components to it.
JPanel contentPane = new JPanel(new BorderLayout());
contentPane.setBorder(someBorder);
contentPane.add(someComponent, BorderLayout.CENTER);
contentPane.add(anotherComponent, BorderLayout.PAGE_END);
topLevelContainer.setContentPane(contentPane);
Atenţie! Ca un avantaj, metoda add şi variantele sale, remove şi setLayout au fost suprascrise, putând transmite contentPane-ului, după cum este necesar. Aceasta înseamnă că se poate scrie:
frame.add(child);
iar “child” va fi adăugat contentPane-ului.
De notat că numai aceste trei metode pot face acest lucru. Aceasta înseamnă că metoda getLayout() nu va returna layout-ul setat cu setLayout().
Permalink
Posted in Java at 1:09 am by rast
Majoritatea aplicaţiilor Java se scriu/programează cu ajutorul claselor din pachetul Swing care pune la dispoziţie trei clase “container” top-level. Aplicaţiile Swing sunt derivate/extensii ale acestor clase.
- JFrame
- JDialog
- JApplet
Utilizând aceste clase trebuie să ţinem cont de următoarele:
- pentru a apărea pe ecran, orice componentă a interfaţei grafice trebuie să fie o parte dintr-o “ierarhie de control”. O “ierarhie de control” este un arbore de componente care are un top-level container ca rădăcină (root).
- fiecare componentă a interfeţei grafice poate fi cuprinsă (inlusă) doar o singură dată, în interiorul altei componente. Dacă o componentă este deja inclusă într-un container, şi se încearcă o includere a ei şi într-un alt container, componenta va fi ştearsă/eliminată din primul container şi adăugată celui de-al doilea.
- fiecare container top-level va avea un “content pane” (panou de conţinut) care, în general vorbind, va conţine (direct sau indirect) componentele vizibile din acest “top-level container” al interfeţei grafice.
- opţional, se poate adăuga un “menu bar” (bară de meniuri), al unui container de nivel superior. Prin convenţie, bara de meniu este adăugată în partea de sus a container-ului, dar în afara “panoului de conţinut”. Unele “look and feels”, cum ar fi cel “Mac OS”, oferă posibilitatea de a poziţiona bara de meniuri într-un alt loc mai adecvat designului general al alicaţiei, cum ar fi în partea de sus a ecranului.
Atenţie! Deşi JInternatFrame “imită” JFrame, cadrele (frame) interne nu sunt, în realitate, top-level containere.
Mai jos, se prezintă un cadru (frame) creat de o aplicaţie. Cadrul conţine o bară de meniuri (dar nu cu meniuri) verde şi, în interiorul “panoului de conţinut”, un mare spaţiu gol, desenat cu galben (practic o componentă-etichetă JLabel galbenă).
Puteţi găsi întregul cod sursă TopLevelDemo.
Ierarhia containerelor pentru acest exemplu de interfaţă grafică simplă este:
Fiecare aplicaţie care utilizează componente Swing are cel puţin un container de nivel superior “top-level container”. Acest container “top-level” este rădăcină (root) a unei ierarhii de containere care conţine toate componentele care apar în interiorul containerului top-level.
Ca regulă, o aplicaţie standalone bazată pe interfaţă grafică Swing, are cel puţin o ierarhie de control cu un JFrame ca rădăcină. De exemplu, dacă o aplicaţie are o fereastră principală şi două ferestre de dialog, atunci aplicaţia va avea trei ierarhii şi deci trei containere top-level. O ierarhie va avea drept rădăcină JFrame, iar fiecare dintre celelalte două va avea un obiect JDialog ca rădăcină.
Un Applet bazat pe componente Swing are cel puţin o ierarhie de control, aceea care are ca rădăcină obiectul JApplet. De exemplu, un applet care apelează un dialog are două ierarhii. Componentele din fereastra browser-ului se află într-o ierarhie de control cu rădăcina în obiectul JApplet. Dialogul are o altă ierarhie de control, cu rădăcina în obiectul JDialog.
Permalink
05.18.08
Posted in Java at 10:55 pm by rast
Nu degeaba vechii egipteni se închinau zeului Ra (Soarele). Razele solare au influenţă complexă asupra omului, nu ne dau numai căldură, ci energii care încă nu pot fi explicate. Medicina, implicit ştiinţa actuală - recunoaşte doar unele dintre acestea: producerea vitaminei D în organismul uman, când este expus radiaţiei solare.
Este recunoscută influenţa vremii (soare sau timp noros), asupra psihicului oamenilor. Cei care manifestă o influenţă mai mare sunt numiţi meteo-sensibili. După părerea mea, toţi oamenii sunt influenţaţi de soare, într-o măsură mai mică sau mai mare. Unii oameni poate nu şi-au pus problema că starea lor psihică proastă: indispoziţie de moment, este dependentă de cerul noros şi de presiunea atmosferică crescută.
Am avut, vreo 3-4 săptămâni, parte de un cer noros, ploi dese şi lungi, motiv pentru care am intrat într-o pauză de idei. De câteva zile vremea este mai îngăduitoare cu noi… deja “mă bubuie” idei noi.
Ca urmare a unei colaborări part-time cu o firmă producătoare de construcţii metalice, realizând un program de Pregătire, Lansare şi Urmărire în Producţie; am rămas cu ample cunoştinţe din domeniul fabricaţiei de bunuri materiale.
Lăsând la o parte modulul de Aprovizionare (NIR-uri, gestionarea magaziilor, stocuri), rămân suficiente problematici de abordat, într-un program în care se urmăreşte stadiul producţiei. Într-un astfel de program, punctul de plecare este “reţeta“, după care se fabrică produsul. În baza reţetei se pot constitui liste de materiale necesare, avându-se în vedere comenzile interne deschise şi lansate în producţie.
Permalink
05.08.08
Posted in Java at 1:52 am by rast
Încep şi eu cu romgleza. Titlul se traduce în româneşte foarte simplu, în cuvintele: “înapoi la Java”. Simplu, simplu, ca traducere, dar ca activitate şi semnificaţie pentru mine ca emitent al titlului, e ceva mai complicat.
Unui client al firmei la care prăşesc, dau cu târnăcopu’ şi astup şanţuri; ia venit ideea, genială - dacă o luăm la bani mărunţi, să ceară nişte funcţionalităţi în plus la programul cel am în custodie şi pe care trebuie să-l întreţin şi adaptez.
Mă plângeam eu că nu prea am activitate de programare; întreţinerea şi adaptarea softului, nu necesită prea multă “scriere de cod”. Acu’ am “scriere de cod” de nu-mi văd capu’ de atâta treabă. Deja încep să-mi fac griji pentru unghiile mele. Protejate atâta vreme (surfat-ul pe net chinuie şoarecu’ mousele, nu tastatura), s-au cam dezobişnuit de tasting.
Ideea a faină şi mă bucură. Aduce întregii aplicaţii funcţionalităţi noi şi de bun simţ. Chiar mă miră faptul că anteriorii clienţi nu au solicitat aceste îmbunătăţiri.
Am JavaScipt-uit-o câteva zile şi acum trec din nou la Java. Încep să mă îngrijorez: aşa cum o veche vorbă populară spune că: “sunt cu fundu-n două luntre” sau “nici în căruţă, nici în teleguţă”… încep să mă simt cu muscă pe căciulă: ori programare web (client-server: JavaScript, PHP), ori stand alone (de data asta Java).
Ca să mă exprim academic: două “segmente de piaţă” destul de separate.
Programarea web are avantajul că poţi arăta oricând şi oricui, ceea ce ai muncit/programat. Îi dai adresa şi gata! Vede singur de ce eşti în stare. Programarea Java, în particular vorbind: ceea ce am făcut eu până acuma, necesită o muncă suplimentară (destul de amplă) pentru a o adapta tehnologiilot Internet. Deja mă bate chinuie gândul “să adaptez din mers” aplicaţia la care lucrez, la tehnologiile web şi să încerc să o promovez. Adaptarea va trebui să fie foarte complexă. Actualmente aplicaţia poate fi utilizată de o gamă foarte redusă de firme. Trebuie o adaptare pentru a găsi un target mai mare. Va trebui să apelez la “sfetnicul nopţii”, poate ştie el mai multe.
Permalink
« Previous entries
