אז מה הjava stack המועדף עליי?

במהלך עבודתי כיועץ JAVA פרילנסר עצמאי, אני מתבקש לעיתים קרובות להמליץ על טכנולוגיות ג'אווה מתאימות לפרויקט מסויים. בג'אווה בניגוד לטכנולוגיות של מיקרוסופט כמו דוט נט, יש מגוון עצום של אפשרויות בבואינו לבחור סביבות עבודה. לכל שכבה באפליקציה יש אינספור פריימוורקים, ספריות וAPI, חלקם הגדול בקוד פתוח ואחרות מסחריות. כל ארכיטקט ויועץ בוחר בSTACK האהוב עליו בהתאם להעדפותיו האישיות וכמובן בהתחשב בדרישות הפרוייקט וביכולות המוצרים השונים. בפוסט זה אפרוס את ההעדפות האישיות שלי שמתאימות למרבית הפרוייקטים אם כי זה כמובן משתנה בהתאם לצרכי הלקוח.

תצורה כללית Best of bread – Non J2EE

J2EE היא טכנולוגיה טובה אבל במקרים רבים מדובר בover kill והיא עמוסה פיצ'רים ושכבות שלא נמצאות בשימוש ומכבידות על המערכת. השימוש בsession Beans למשל כשהרבה פעמים אין צורך בכך ובכלל הEJB Container המסורבל כאשר הפונקציונליות היחידה שבאמת צריך היא JPA שאפשר לקבל גם ללא EJB (באמצעות Hibernate למשל). בנוסף, בJ2EE יש נטייה להצמד לשרת של יצרן מסויים ודי מהר מתחילים להשתמש בפיצ'רים היחודיים לאותו מוצר. זה גורם לאפליקציה להיות Non Portable כשרוצים לעבור לשרת אחר. פעמים רבות נתקלתי בפרוייקטים שרצים מעל J2EE כשהשרת משמש ללא יותר מאשר Servlet Container. הפלטפורמה של JEE מסבך דברים פשוטים: WAR פשוט הופך לEAR מורכב, Deployment Descriptiors מיותרים בחלק מהגרסאות, ובגלל שהשרתים בדרך כלל תפורים מראש קשה להחליף מודול ספציפי במקרה הצורך (למשל לשדרג לגרסה חדשה יותר). לדעתי כדאי להמנע ככל שאפשר משימוש

Application Server – Apache Tomcat

שרת האפליקציות וServlet Container הנפוץ בעולם. היחיד שיכול אולי להתחרות בו הוא Jetty אבל התיעוד הרב, וותק רב השנים, האינטגרציה הטבעית עם שרת Apache כשרת WEB, והאמינות של ארגון Apache הופכים אותו לאופציה הטובה ביותר.

ORM Persistence – Hibernate JPA Annotations

למרות שעדיין יש ארגונים המפתחים בhibernate בתוצרה הישנה קרי, שימוש בXML על מנת להגדיר את המיפוי בין המחלקות לטבלאות, השימוש בJPA annotations מהווה יתרון מכמה סיבות: ראשית זה מאפשר מעבר לEJB במידה ורוצים בעתיד להעביר את האפליקציה לJEE. שנית, הקוד הרבה יותר קריא וברור כשמעל לכל Property בקוד מופיע הגדרות המיפוי שלו. כמו כן זה מוריד את הצורך לתחזק XML שבמקרים רבים הופך להיות ארוך ומסורבל.

Dependency Injection – SPRING

במקומות רבים מוותרים לגמרי על השימוש בDI ובSPRING בפרט אבל לדעתי זהו פיצ'ר חשוב שמייעל ומפשט את הקוד בצורה משמעותית. הבחירה שלי בSPRING ולא בפריימוורקים אחרים כגון Google Guise היא שSPRING הוא הרבה יותר מרק DI. במקרה הצורך אפשר למצוא מענה טוב לכמעט כל טכנולוגיית ג'אווה קיימת: JMS, JPA, Security, RMI, Web Service, מימוש טוב לAOP ועוד ועוד. היופי בSPRING הוא היותו מבוסס על POJO כך שתמיד קל להבין איך דברים עובדים והכי חשוב: אפשר לשלוט בכמות הSPRING שמשתמשים בו בקוד. החל משימוש מועט רק בDI וכלה באפליקציית SPRING מלאה כולל MVC ושאר הפיצ'רים שהפריימוורק הענק הזה מציע.

UI – Rich Client with Adobe Flex

זה אמנם לא ג'אווה ולא WEB קלאסי אבל כיום אין תחליף לפלקס וליכולות שהוא מציע באפליקציות שדורשות קליינט מורכב וברמה גבוהה. יש כמה בעיות בUI רגיל מבוסס HTML וAJAX: ראשית הקליינט לא אמין. Exception יכול לגרום לכל הדף לעוף מבלי יכולת שחזור, ניתוק זמני מהשרת גורם לעיתים קרובות לאיבוד מידע, בעיית תאימות בין דפדפנים, קושי לפתח אלמנטים גרפיים מורכבים, ועוד. שורש הבעייה בממשקי WEB נעוץ בעובדה שהממשק בסופו של דבר בנוי על HTML. הבעייה ששפה זו מלבד היותה מיושנת, יועדה במקור ליצירת מסמכים עשירים ולא לממשקי משתמש. אין גרפיקה ווקטורית, אין קומפוננטות UI נפוצות כמו Tree והקומפוננטות הקיימות מספקות פונקציונליות שמתאימה למסמך ולא לאפליקציה. קחו למשל את Table, על מנת שהוא ייראה כמו טבלה מודרנית עם אפשרות להזזת עמודות, מיונים, פילטרים וכו' צריך לכתוב קוד רב ובדרך כלל להשתמש בכלל באלמנטים אחרים כמו DIV ולא בTABLE של HTML. הפריימוורקים הרבים הקיימים מבוססים על קוד JavaScript שמבצע מניפולציות על אלמנטים בHTML ו"אונסים" אותם כך שייראו כמו UI נורמלי. הדבר היחיד שיכול לשנות את התמונה הוא HTML5 אבל יש עוד דרך ארוכה עד שנוכל להשתמש בתקן זה. ראשית צריך שהתקן יסגר ויתמך בכל הדפדפנים, אחר כך צריך שחברות יפתחו ספריות קומפוננטות מבוססות HTML5. הcanvas כנראה יספק בסיס מתאים אבל מישהו צריך לפתח ולפרסם פקדים שיהיה ניתן לעבוד איתם. כך שבנתיים מבחינת טכנולוגיות זמינות ובוגרות FLEX היא האופציה הטובה ביותר לפיתוח מהיר של ממשקים גרפיים עשירים.

]]> http://www.j2ee.co.il/%d7%94%d7%a2%d7%93%d7%a4%d7%95%d7%aa%d7%99%d7%99-%d7%94%d7%90%d7%99%d7%a9%d7%99%d7%95%d7%aa-%d7%9c%d7%97%d7%91%d7%99%d7%9c%d7%aa-%d7%94%d7%92%d7%90%d7%95%d7%95%d7%94-%d7%94%d7%9e%d7%95%d7%a9%d7%9c/feed/ 0 http://www.j2ee.co.il/%d7%94%d7%a2%d7%91%d7%a8%d7%aa-%d7%98%d7%95%d7%a4%d7%a1-%d7%9cxml-%d7%9eadobe-flex-actionscript3-%d7%9cjava-%d7%95%d7%91%d7%97%d7%96%d7%a8%d7%94/ http://www.j2ee.co.il/%d7%94%d7%a2%d7%91%d7%a8%d7%aa-%d7%98%d7%95%d7%a4%d7%a1-%d7%9cxml-%d7%9eadobe-flex-actionscript3-%d7%9cjava-%d7%95%d7%91%d7%97%d7%96%d7%a8%d7%94/#comments Sun, 24 Jan 2010 20:10:50 +0000 ‫admin‬ http://www.shefertech.com/?p=97

כמתכנת FLEX פרילנסר עצמאי, מצאתי מקרים בהם הלקוח לא עובד בFramework מסודר לתקשורת Client-Server. במקרים כאלה לעיתים יש צורך לעשות Serialize לטופס ולהפוך אותו לפורמט גנרי כמו XML על מנת לשלוח אותו לשרת כלשהו (למשל J2EE Server) ע"י פרוטוקול כמו HTTP או SOAP Web Service. הנה פונקציה פשוטה שכתבתי שלוקחת טופס FLEX, מבצעת עליו סריקה רקורסיבית ושולפת את כל השדות שלו (TextInput) ומחזירה XML עם רשימת השדות והערכים שלהם.
כמו כן מצורף קוד בג'אווה שלוקח XML כזה והופך אותו לJava Bean ובמידה ובBean יש properties תואמים הם יקבלו את ערכי השדות. יש גם פונקציה הפוכה שלוקחת XML וממלאת את השדות בטופס FLEX.

יש להוסיף את הספריות האלה לקוד:

	import flash.utils.Dictionary;
	import mx.controls.TextInput;
	import mx.core.Container;

הנה הפונקציה (למעשה שתי פונקציות) שלוקחת טופס ומחזירה XML:

		public static function viewToXml(className:String, view:Container):String{
			var xml:XML = <bean class={className}></bean>;
			var xmlFinal:XML = addControlsToXml(xml, view);
			return '<?xml version="1.0" encoding="UTF-8"?>' + xmlFinal;
		}

		private static function addControlsToXml(xml:XML, view:Container):XML{
			var controls:Array = view.getChildren();
			for (var i:int; i<controls.length; i++){
				if (controls[i] is TextInput){
					var component:TextInput = controls[i] as TextInput;
					var child:XML = <property name={component.id}>{component.text}</property>;
					xml.appendChild(child);
				}
				if (controls[i] is Container){
					addControlsToXml(xml, controls[i] as Container);
				}
			}
			return xml;
		}

והפונקציה שמקבלת XML וממלאת את הטופס בהתאם:

		private static function xmlToView(props:Dictionary, view:Container):void{
			var controls:Array = view.getChildren();
			for (var i:int; i<controls.length; i++){
				if (controls[i] is TextInput){
					var component:TextInput = controls[i] as TextInput;
					if (props[component.id] != null){
						component.text = props[component.id];
					}
				}
				if (controls[i] is Container){
					xmlToView(props, controls[i] as Container);
				}
			}
		}

ועכשיו לקוד בג'אווה. תצטרכו להוסיף את הספריות הבאות:

import java.io.ByteArrayInputStream;
import java.io.StringWriter;
import java.lang.reflect.Method;
import java.util.Iterator;
import java.util.Map;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathFactory;

import org.apache.log4j.Logger;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

קבלת XML והפיכתו לJava Bean:

	public static Object xmlToBean(String xmlStr){
		DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
		DocumentBuilder documentBuilder = null;
		try {
			documentBuilder = documentBuilderFactory.newDocumentBuilder();
			Document doc = documentBuilder.parse(new ByteArrayInputStream(xmlStr.getBytes("UTF-8")));
			XPath xpath = XPathFactory.newInstance().newXPath();
			Node bean = (Node)xpath.evaluate("//bean", doc, XPathConstants.NODE);
			if (bean != null){
				NamedNodeMap attributes = bean.getAttributes();
				Node cls = attributes.getNamedItem("class");
				String clsName = cls.getNodeValue();
				Object obj = Class.forName(clsName).newInstance();
				NodeList props = (NodeList)xpath.evaluate("//property", doc, XPathConstants.NODESET);
				Class cl = obj.getClass();
				for (int i=0; i<props.getLength(); i++){
					String propName = props.item(i).getAttributes().getNamedItem("name").getNodeValue();
					String propValue = props.item(i).getTextContent();
					String ch = propName.substring(0, 1).toUpperCase();
					String methodName = "set" + ch + propName.substring(1);
					Method[] methods = cl.getMethods();
					for (Method method : methods){
						if (method.getName().equals(methodName)){
							Class[] paramTypes = method.getParameterTypes();
							for (Class param : paramTypes){
								if (param.getName().equals("java.lang.String")){
									method.invoke(obj, propValue);
								}
								else if(param.getName().equals("int")){
									method.invoke(obj, Integer.valueOf(propValue));
								}
								else if(param.getName().equals("long")){
									method.invoke(obj, Long.valueOf(propValue));
								}
							}
						}
					}
				}
				return obj;
			}
		} catch (Exception e) {
			log.error(e);
		}
		return null;
	}

והחלק האחרון: לקחת Java Bean ולהפוך אותו לXML:

	public static String beanToXml(Object obj){
			DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
			DocumentBuilder documentBuilder = null;
			try {
				documentBuilder = documentBuilderFactory.newDocumentBuilder();
			} catch (ParserConfigurationException e) {
				log.error(e);
			}
			Document doc = documentBuilder.newDocument();
			Element rootElement = doc.createElement("bean");
			rootElement.setAttribute("class", obj.getClass().getName());
			Method[] getters = obj.getClass().getMethods();
			for (Method getter : getters){
					if (getter.getName().indexOf("get") == 0)
					if (getter.getParameterTypes().length == 0)
					if (!getter.getName().equals("getClass")){
						StringBuffer prop = new StringBuffer(getter.getName().substring(3));
						String ch = prop.substring(0, 1).toLowerCase();
						prop.replace(0, 1, ch);

						Element propElement = doc.createElement("property");
						propElement.setAttribute("name", prop.toString());
						try {
							propElement.setTextContent(getter.invoke(obj).toString());
						} catch (Exception e) {
							e.printStackTrace();
						}
						rootElement.appendChild(propElement);
					}
			}
			doc.appendChild(rootElement);

			StringWriter stw = new StringWriter();
            Transformer serializer;
			try {
				serializer = TransformerFactory.newInstance().newTransformer();
				serializer.transform(new DOMSource(doc), new StreamResult(stw));
			} catch (Exception e) {
				log.error(e);
			}
            return stw.toString();
	}

להבין את צרכי הלקוח
אחד הדברים החשובים לפרילנסר בתחום הפיתוח הוא להבין את צרכי הלקוח. הרבה פעמים דברים שלא היו מתקבלים בחברות טכנולוגיות מקובלים אצל הלקוחות. לקוח אחד ביקש להתממשק מול מערכת הERP שלו כך שכל עדכון בERP בטבלה מסויימת יעדכן אוטומטית את האפליקציה שלו. האופן שבו הוא עשה את זה היה שהERP הנפיק אחת לשעה קובץ טקסט עם רשימת השינויים ושמר אותה בתיקיה משותפת. באפליקציה החיצונית היה Timer שפעם בשעה קרא את הקובץ וייבא את הנתונים. היועצים הציעו להחליף את המערכת בטענה שזו שיטה גרועה. הם המליצו על SOA, Web Services שימוש במוצרי תווכה שונים ושרתי אינטגרציה. אבל לשאלה הפשוטה של הלקוח לאף אחד לא היה מענה: מה רע במצב הקיים?

(לא) להיצמד רק למה שמכירים
פרילנסרים ועצמאים רבים נוהגים לפתח בטכנולוגיות שהם מכירים ואוהבים. הרבה פעמים אני מזהה "טביעת אצבע" של מפתח שנצמד לסביבה מסויימת. איש מקצוע אמיתי מסוגל תעלות מעל ההעדפות האישיות שלו ולתכנן את הפתרון הטוב ביותר ללקוח בהתבסס על הכלים והטכנולוגיות המתאימות ביותר. אין סיבה לבחור בדוט נט כשאפשר לפתח אתר תוכן בPHP עם פלטפורמת ניהול תוכן מוכנה במהירות רבה יותר ובעלויות נמוכות יותר.

הכנסת טכנולוגיות מגוונות מדי לארגון
עוד בעיה נפוצה היא שיועצים עצמאים נוטים למצוא את הכלי המתאים ביותר לפתרון הספציפי מבלי להתחשב באסטרטגית הIT של הארגון. בחברה מסויימת היה ERP של SAP, כמה אפליקציות דוט נט, בסיס נתונים של אורקל ופורטל ארגוני של SAP Portal. כשהם ביקשו לפתח אפליקציה תפעולית מסויימת, הקבלן בחר בOracle JDeveloper על שרתי Oracle IAS לפיתוח התוכנה. התוכנה היתה תוכנה קטנה ששרתה צורך מסויים והבעיה נוצרה כשבארגון "צמח" לפתע סט שרתי חדשים, סביבת פיתוח, ופלטפורמה שצריך לתחזק. זה דרש הקצאה של כוח אדם, יועצים, חומרה ורשיונות תוכנה רק בשביל אותה אפליקציה. אז אומנם הפיתוח הראשוני היה מהיר אבל התחזוקה רבת השנים שלא לדבר על שינויים ותיקונים גררו את הלקוח להוצאות כבדות ומיותרות. הפתרון הנכון היה לבחור באחת הפלטפורמות שנמצאות כבר בארגון ולפתח על בסיסה.

עומס טכנולוגיות – Over Kill
בעיה נוספת שמאפיינת בעיקר את הפרילנסרים חובבי הטכנולוגיות והגאדג'טים הוא שימוש מופרז בכלים מתוחכמים שבסופו של יום לא מספקים ערך מוסף ללקוח או אפילו פוגעים בו. הרבה פעמים מתכנתים רוצים להשתמש בטכנולוגיות המשוכללות והנוצצות ביותר כשמספיק משהו הרבה יותר בסיסי. למשל, שימוש נפוץ בשרתי JBoss ובJ2EE מנפחים פרוייקט ג'אווה כשהרבה פעמים כל מה שצריך הוא Servlet Container כמו Tomcat בשילוב עם Hibernate. אין טעם להשתמש בשרת אפליקציות כבד אם לא מתכוונים לנצל את הפונקציונליות שלו.

יותר מדי גנריות
נושא שמאפיין במיוחד פרילנסרים שהגיעו מחברות הי-טק ועברו לשוק הIT והאנטרפרייז. בחברות הי-טק בדרך כלל מפתחים מוצרים ופלטפורמות שמיועדים למגוון גדול של לקוחות. לכן מקפידים לשמור על גמישות מקסימאלית, יכולת הרחבה, ומוצר שניתן להכניס בו שינויים עתידיים. הרבה פעמים זה גורר דיזיין מסובך שכולל רמות הפשטה והפרדה בין השכבות השונות. צריך לזכור שבשורה התחתונה הלקוח רוצה אפליקציה עובדת ורוב הסיכויים שהוא ישאיר אותה כפי שהיא ל7-8 שנים הבאות. אין טעם לפתח מודולים ושכבות מעבר לסטנדרטים המקובלים (MVC וכו'). גם אם בסוף יהיה צורך להכניס שינויים, תמיד אפשר להתאים את הקוד והסיכוי לא שווה את הסיכון (או את הבזבוז ליתר דיוק).

הצמדות לאפיון
לקוחות מצפים מהיועצים החיצוניים להגדיל ראש באופן סביר ומידתי. בדרך כלל כשניגשים לפתח מערכת מידע בארגון גדול, מקבלים אפיון מפורט לפי סטנדרטים קבועים. במהלך הפיתוח כמעט תמיד מתגלים טעויות באפיון: מסכים לא הגיוניים, מידע חסר, פיצ'רים חסרים. הדרך הנכונה לטפל בנושאים הללו היא להעלות אותם ולא להתעלם מהם. צריך לזכור שאת האפיונים כותבים מנתחי מערכות שלא תמיד רואים את התמונה המלאה בעת שלב התכנון. גם נתקלים ברעיון שיכול לחסוך זמן, או בדרכים לשיפור כדאי להעלות אותם.

יצירתיות יתר
מאידך, מתכנתים עצמאים רבים אוהבים לעבוד באופן עצמאי כשהם קובעים בעצמם איך יראה המוצר המוגמר. זו טעות. הרבה פעמים אני נתקל במשפטים כמו "אל תדאג, אני יודע בדיוק מה אתה צריך זה ייראה סוף הדרך". צריך לזכור שמה שנראה הגיוני למתכנת לא בהכרח מתאים למשתמשי הקצה שבדרך כלל הם בעלי רקע שונה. אפילו אנשי מערכות המידע בתוך הארגון (הלקוח) לא תמיד מצליח להוציא מוצר שמתאים למשתמשים אבל לפחות הוא קרוב יותר לשטח מאשר המפתח.

בגיל 10 אבא שלי הביא הביתה את המחשב הראשון שלנו. זה היה אפל 2 עם מסך CRT שחור לבן (ירוק ליתר דיוק). למדתי לתכנת עליו בביסיק ומאז היה לי ברור שבעתיד אעסוק בתחום. בגיל התיכון התחלתי לתכנת ברצינות, בהתחלה בפסקל ואחר כך בC ובC++. היה זה בגיל 16 שמכרתי את התוכנה הראשונה שלי: פיתחתי תוכנת ניהול עבור חברת הובלות קטנה. הקוד נכתב בC על קומפיילר של בורלנד לwindows. הממשק נכתב בWIN16 API ורץ על Windows 3.11. האמצעים היו פרימיטיבים: ברוב הבתים לא היה אינטרנט נגיש ואת רוב התיכנות נאלצתי ללמוד מכמה ספרים ומקבצי הHELP שהגיעו עם הקומפיילר. לא ידעתי מה זה דאטהבייס וכל המידע נשמר בקבצי ASCII על הדיסק. התוכנה השתמשה ברשימות מקושרות ועצים בינארים כדי לאחסן את הרשומות בזיכרון וכל זאת על מחשב 486 מוגבל יחסית. אבל זה עבד, ואפילו עבד טוב.

לאחר הצבא התחלתי לעבוד בחברת סטראטאפ קטנה בשם טופטיר. זמן קצר לאחר מכן החברה נמכרה לSAP ב400 מליון דולר והמשכתי לעבוד בסאפ למעלה מ4 שנים. כשעזבתי את סאפ, הקמתי עסק משלי בשם "שפר מערכות" (ומכאן השם של האתר הזה) ועבדתי כמתכנת ויועץ פרילנסר עצמאי עבור ארגונים שונים. בין לקוחותיי: בתי הזיקוק, פז, הנוער העובד והלומד, GigaSpaces, מכללת אינטרביט, ועוד. לאחר מכן הצטרפתי לחברת דנשיר מערכות על מנת להקים את חטיבת הJava והNetWeaver ועמדתי בראש הקבוצה למעלה משנה כשאנחנו מבצעים פרוייקטים עבור חברות שונות: נטפים, בתי זיקוק, אוניברסיטת חיפה, מירס, תעשייה אווירית, CNW ועוד. התחנה הבאה היתה חברת אינפורמטיקה שם מלאתי תפקיד של מתכנת בכיר – Principle Software Engineer.

ב2010 הקמתי חברת מגהסופט ומאז אני מכהן כמנכ"ל וכמובן ממשיך לפתח ולכתוב קוד במסגרת החברה. MegaSoft עוסקת בפיתוח עבור ארגונים, חברות הי-טק וסטארטאפים במגוון תחומים ובעיקר בג'אווה, Flex, מובייל ופלטפורמות קוד פתוח.

חוץ מזה אני תמיד מחפש את ההרפתקה הבאה ואשמח לקבל פניות, הצעות, הערות והארות.