העברת טופס לXML מAdobe Flex ActionScript3 לJava ובחזרה

כמתכנת 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();
	}

איך לעבור מבחן וראיון מקצועי בחברת הי-טק

בין אם אתה שכיר ובין אם אתה פרילנסר עצמאי, הרבה פעמים תדרש לעבור מבחן מקצועי בתיכנות כדי לקבל את המשרה הנחשקת. להלן קובץ המלצות וכללים להצלחה במבחן קצועי בחברות הי-טק בתחום התוכנה.

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

  1. כמה זמן יארך המבחן?
  2. מי מעביר את המבחן?
  3. האם המבחן הוא בעל פה במתכונת של ראיון, מבחן על דף או מבחן על מחשב?
  4. מהם נושאי המבחן בכלליות?

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

ככלל, קיימים שלושה סוגים עיקריים של מבחנים:

  • מבחן בעל פה מול מראיין
  • כתיבת משימת קוד
  • קובץ של שאלות בדרך כלל אמריקאי

כעת נסקור כל אחד מסוגי הבחינות ונראה כיצד יש להתכונן אליהם ומה צריך לעשות כדי לעבור אותם בהצלחה.

מבחן בעל פה מול מראיין

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

דבר על משהו שאתה שולט בו ב100%

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

בחר נושא עם מימוש מעניין שאפשר לפתח סביבו דיון

הצגת הודעת משתמש על המסך הוא לא משהו משמעותי למשל. עליך לבחור משהו שיכלול טכנולוגיה מעניינת, מימוש מורכב ורצוי בעל מאפיינים קלאסים כגון MVC, ירושה ותכנון OOP מורכב, שימוש מיוחד בטכנולוגיה. נושאים מעולים לדיון יהיו: פתרון של בעיית ביצועים, מימוש של Caching, Clustering, וכו', ארכיטקטורת שכבות כלשהי: DAO, ORM, אלגוריתמים כמו: עצי משחק, מכונות מצבים, פתרונות באמצעות תורת הגרפים, בעיות Multi Threading וסינכרון.

לא לדבר על דברים שהמראיין לא מסוגל לפתח סביבם שיחה

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

בחר משהו מהניסיון הרלוונטי ביותר

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

הכן פרוייקט לגיבוי

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

מה לגבי שאר השאלות?

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

כתיבת משימת קוד

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

הכנה מוקדמת

ברוב המקרים תידרש לכתוב תוכנית console שמשתמשת בקלט פלט סטנדרטי בשורת פקודה. מעבר לזה רוב המימוש יכלול את רכיבי השפה הבסיסיים: מערכים, מבני נתונים, ניתוח Strings, וכו'. כדאי לחזור על דברים בסיסיים שאולי שכחת על מנת שלא לבזבז זמן יקר: פתיחת פרוייקט חדש בסביבת הפיתוח, פקודות קלט פלט למסך, הגדרת קלאסים מסוגים שונים: interface, abstract, החבילות המכילות את מבני הנתונים הנפוצים   (List, Hash) ועוד. עוד נושא קריטי להצלחה במבחן הוא: Design Patterns. DP הוא נושא שיחסית קל ללמוד ולזכור ומאידך שימוש נכון בDP משאיר רושם טוב ומקצועי. כדאי מאוד להכיר את התבניות של הGOF ולדעת איך להשתמש בהן.

להלן דגשים למבחן בכתיבת קוד:

אל תתעכב על קריאת האפיון ואל תרד לפרטים

הרבה פעמים האפיון יתפרס על כמה עמודים באנגלית ולקרוא אותו עד הסוף ולהבין אותו באופן מלא יכול לקחת 15-20 דקות. זהו זמן יקר בהתחשב בעובדה שרוב המבחנים אורכים כשעתיים (זמן מוגבל). כדאי לקרוא ברפרוף ולעבור לדוגמאות (בדרך כלל מופיעות במסמך) ולהבין בגדול מה מצפים. אף אחד לא יפסול אותך כי המבחן הדפיס "hello moshe" במקום ""hello david.

הקדש 10 דקות לתכנון הפתרון

מומלץ לסרטט את הפתרון על דף נפרד. להגדיר את המחלקות העיקריות והירושה, את המופעים העיקריים של האובייקטים והיחסים בינהם.

לעולם תתחיל מהגדרת כל המחלקות והפונקציות

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

סטנדרטים מומלצים

חלק גדול מהמבחן הוא לבדוק האם המועמד משתמשת בBest Practices ובשיטות מקובלות ועד כמה הקוד שלו איכותי.

שמות מחלקות, משתנים, ומתודות

יש להקפיד על שמות בסטנדרט מקובל. מועמד שיקרא למשתנים שלו: a,b,c במקום: customer, person, manager יאבד נקודות במהירות. כנ"ל לגבי שימוש נכון באותיות גדולות וקטנות כפי שמקובל בשפה הרלוונטית.

תיעוד

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

שימוש מושכל בפולימורפיזם

בג'אווה למשל, אפשר ליצור רשימה בכל אחת מהדרכים הבאות:

ArrayList list = new ArrayList ();

List list = new ArrayList();

List<String> list = new ArrayList<String>();

על אף שהתוצאה בשלושת המקרים תהיה זהה המקרה השלישי הוא הנכון ביותר. הרשימה מוגדרת כList שהינו interface כך שניתן להחליף את המימוש בקלות (למשל לLinkedList). הרשימה היא type safe כך שמובטח שתכיל רק אובייקטים מסוג String.

שימוש נכון בלולאות

נניח ויש לנו את הרשימה מהדוגמא הקודמת. כיצד נדפיס את אברי הרשימה?

For (int i=0; i<list.size(); i++)

System.out.println(list.get(i)):

(for String s : list)

System.out.println(list.get(i)):

כדאי להכיר את הלולאה for each (החל מג'אווה 1.5) ולהשתמש בה כשאפשר.

Design Patterns מומלצים

סטטיסטית, כמעט כל מרואיין שנשאל אילו DP הוא מכיר יענה Singleton או Factory. כדי להראות מקצועיות כדאי להכיר עוד כמה DP מלבד השניים המוכרים הללו. במבחנים המקצועיים יש כמה DP שיכולים להיות שימושיים, ואילו אחרים בדרך כלל לא יהיו רלוונטים. נהוג לחלק את רשימת הDP של הGOF לשלושה תתי רשימות: Creational Patterns, Structural Patterns, Behavioral Patterns. הStructural כמעט ולא רלוונטים למבחנים כיוון שבדרך כלל בשעתיים אי אפשר להגיע לרמות OO שמתאימות לדפוסים אלה. למעט Composite שכדאי להכיר כי בהרבה מבחנים מבקשים להגדיר מבנה בצורת עץ היררכי כלשהו.

הCreational מתאימים במקצת אם כי לרוב אין צורך בהם שוב בגלל שהקוד מצומצם למספר קטן של קלאסים.

הBehavioral הם המתאימים ביותר ורצוי לשנן אותם ולהשתמש בהם בעת הצורך.

מבחן אמריקאי

לרוב קשה להתכונן למבחן אמריקאי כיוון שאין לדעת אילו נושאים יופיעו ועל מה יהיה המיקוד. אבל ישנו דפוס שחוזר על עצמו לעיתים קרובות וכדאי להגיע מוכן אליו. כיוון שבכל תחום בעולם ההי-טק קיימים מאות טכנולוגיות שונות, ספריות, API, פלטפורמות וחבילות תוכנה אין כל כך טעם לבחון מועמד על טכנולוגיה מסויימת כיוון שקיים סיכוי טוב שאותו מועמד לא השתמש בטכנולוגיה זו ולכן לא יידע לענות על השאלות מה שלא מעיד על הידע והיכולות האמיתיות שלו. לכן נהוג לקחת את המכנה המשותף הנמוך ביותר שמצופה מכל מועמד להכיר וזה בדרך כלל החוקים של שפת התיכנות עצמה ונושאים סביב הליבה של הטכנולוגיה. הנושאים הנפוצים ביותר הנשאלים הם על: OOP וחוקי ירושה, פולימורפיזם, Up casting, down Casting, בעיות סינכרוניזציה וmulti Threading, מבני נתונים בסיסיים (רשימות, עצים בינארים), מערכים ומחרוזות, העברת פרמטרים By Value וby Reference, טיפול בexceptions כולל חוקי ההיררכיה, שאלות על פונקציות שונות במחלקות String וobject (רלוונטי לג'אווה ולדוט נט), Reflection, שימוש בbreak וcontinue ועוד.

בין הנושאים המתקדמים יותר אפשר למצוא: כוונון של הGC, JVM/CLR, סוגים שונים של Collections ודרך התנהגותם, מילות שמורות בשפה שנדיר להשתמש בהם, דקויות בין טיפוסי משתנים והמרות (int, long, double, float, char).

כללים לפיתוח אבטיפוס, הדגמה (Demo), ובדיקת התכנות (POC)

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

קוד גנרי או פתרון זמני?

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

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

כמובן שיש לבחון כל מקרה לגופו. יש מצבים בהם כדאי לפתח "כמו שצריך" במיוחד כאשר בטוחים בתצורה הסופית ואין ספק לגבי המשך הדרך.

להתמקד במינימום ההכרחי

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

רכיב

המלצה

הערות בקוד

רק במקרים בהם יש כתיבה יוצאת דופן שעלולה להיות לא מובנת

Log

אין צורך. המוצר ממילא לא ירוץ בProduction והוא פשוט מספיק כדי לדבאג במקרה הצורך

Unit Tests

לאנשי הTDD ברור שצריך. לאחרים – מומלץ בדיקות פשוטות בלי Mocks ושאר סביבות מתוחכמות

Integration Tests

אין צורך

שימוש בFrameworks

האם להתשמש בפריימורקים כמו SPRING או Hibernate או שמא להסתפק בקוד "רגיל"? במידה ואתה בקיא לחלוטין בסביבה מסויימת והיא יכולה לחסוך זמן בפיתוח זה מומלץ. לעומת זאת, פריימוורק שמתכוונים ללמוד ולהתשמש בו במוצר הסופי לא כדאי להתעכב איתו עבור הPOC.

משתנים Hard coded

לא צריך להשאיר דברים hard coded כמו מחזרוזות בתוך פונקציות. עדיף להוציא הכל למשתני const. מצד שני אין צורך להוציא דברים החוצה (XML, DB, קובץ) אפשר לשנות את הקוד במידה ורוצים לערוך משהו

OOP

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

Bayby Agile

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

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

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

יש למה לחכות…

טוקבקים ככלי דמוקרטי – הצעת יעול

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

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

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

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

מפתח פרילנסר: עשה ואל תעשה בעבודה מול לקוח

להבין את צרכי הלקוח
אחד הדברים החשובים לפרילנסר בתחום הפיתוח הוא להבין את צרכי הלקוח. הרבה פעמים דברים שלא היו מתקבלים בחברות טכנולוגיות מקובלים אצל הלקוחות. לקוח אחד ביקש להתממשק מול מערכת ה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 וכו'). גם אם בסוף יהיה צורך להכניס שינויים, תמיד אפשר להתאים את הקוד והסיכוי לא שווה את הסיכון (או את הבזבוז ליתר דיוק).

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

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

לפתור בעיה בלתי פתירה

אסייג ואומר שמאמר זה מיועד בעיקר למתחילים אבל גם מתכנתים וותיקים יכולים למצוא בו עניין. פעמים רבות אנחנו נתקלים בבעיה בעבודה שבמבט ראשון נראית בלתי פתירה. אני אישית, אני מאמין שההבדל בין מתכנת טוב למתכנת מעולה הוא ביכולת לעקוף ולמצוא פתרונות שלא נפתרים באמצעות ההגיון הפשוט. אני לא מדבר על אלגוריתם מסובך או קוד שלא רץ כראוי – בשביל זה יש מספיק כלים ומתודולוגיות. אני מדבר על מצבים שבדרך כלל לא נמצאים בשליטתנו.
דוגמא: אתה מפתח מול שרת אפליקציות ובשלב כלשהו כל נסיון להעלות את האפליקציה (Deploy) זורקת שגיאה: The server failed to deploy the application: error #4522
אתה בטוח שלא עשית שום דבר חריג, אין שום דרך לדבאג את זה ואין שום שינוי בקוד שיכול לתקן את זה. האפשרות הסבירה ביותר למרבית האנשים היא לפנות למישהו מנוסה "תותח" כמו שאוהבים לכנות אותם שיפתור את הבעיה. אתה תצא בסדר: זה לא באג בקוד שלך ולא עשית שום דבר רע. אבל האם שאלת את עצמך פעם איך עובד כלשהו הגיע למצב שהוא נחשב "תותח"? למה שלא תהיה אחד כזה בעצמך?
כמובן שמרכיב הניסיון הוא חשוב אבל יש עוד דברים שמשפיעים על יכולת פתרון בעיות. יש מתכנתים שאחרי שנתיים נחשבים למומחים ויש אחרים שגם אחרי 10 שנים נשארים בינוניים. להלן סדר פעולות שיכול לסייע בפתרון של כל בעיה:

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

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

צמצם אפשרויות – אלימינציה
הבעיה יכולה להיות במקומות שונים: בשרת, באפליקציה שלך, בדאטה בייס, בתקשורת, במערכת חיצונית כלשהו או במודול מסויים במערכת. זה הזמן לפסול אפשרויות. תתחיל מלבדוק האם השרת עובד עם אפליקציה אחרת? האם אתה יכול להעלות אפליקציה סתמית (hello world) ולהפעיל אותה? זה ייקח 5 דקות של עבודה ויכול לחסוך שעות של בדיקות.

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

חיפוש בגוגל ובאינטרנט
יעיל במיוחד בעבודה מול מערכות חיצוניות. העתק את שורת השגיאה ותריץ בגוגל. בהרבה מקרים ה2-3 תוצאות הראשונות יתנו הסבר מדויק של הבעיה ופתרונה. לפעמים צריך קצת להוסיף מילים לשורת החיפוש כמו: "deployment error #333 WebLogic 8.1" אבל העניין ברור. 20 שניות שיכולות לחסוך שעות של עבודה.
אגב, בדרך כלל חיפוש בגוגל יעיל יותר מחיפוש באתר החברה. גוגל פשוט מאנדקס את העמודים בצורה הרבה יותר יעילה ממרבית מנועי החיפוש הפנימיים. נסו לחפש מידע בגוגל לעומת MSDN או האתר של אורקל ותמצאו שגוגל נותן תוצאות הרבה יותר טובות. רק אם לא מוצאים בגוגל כדאי לחפש באתרים אחרים דבר שבדרך כלל לוקח יותר זמן.

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

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

אודות הבלוג הזה – מי אני

shlomo_schwarcz

מאז היותי ילד אני מתכנת בשפות שונות. בשנים האחרונות עסקתי בעבודות ובפרוייקטים רבים בתחום פיתוח תוכנה: החל מחברות ענק כמו SAP ואינפורמטיקה, דרך סטאטראפים כמו GigaSpaces ועד חברות תעשיתיות שונות כמו בתי זיקוק, פז ונטפים. תחום ההתמחות שלי הוא כל מה שקשור לטכנולוגיות ג'אווה: J2EE, EJB, JSP, Servles, JDBC, JNI, RMI, Spring, Hibernate, JSF, SWING. בנוסף עסקתי רבות גם בתחומי הסאפ השונים ובעיקר בNetWeaver, SAP Portal, WebDynpro, Visual Composer ושאר טכנולוגיות ג'אוואיות של SAP. וכמובן כדי להשלים את התמונה גם .C++, NET, C#, ASP מוכרים לי היטב.

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

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

נשתמע,
שלמה שוורץ
shlomo@shefertech.com

נסיון מקצועי

SAP Labs

על החברה
SAP הינה חברת התוכנה השלישית בגדולה בעולם ונחשבת למובילה עולמית בשוק התוכנות לניהול ארגוני. החברה המציאה את תוכנת הERP – תכנון משאבים ארגוניים, תוכנה המתיימרת לנהל את משאבי הארגון מקצה לקצה: משאבי אנוש, פיננסים, לוגיסטיקה, ייצור, הפצה, רכש, מלאי, מכירות ועוד.
ב2001 רכשה SAP את חברת TopTier הישראלית שנוסדה ע"י שי אגסי תמורת 400 מליון דולר במזומן. זמן קצר לפני הרכישה התחלתי לעבוד בטופטיר כמפתח C++. המוצר של טופטיר היה פורטל ארגוני (Enterprise Portal). מדובר באפליקציית WEB שמאפשרת לעובדים בארגון לגשת לכל מערכות המידע של הארגון דרך אתר פשוט ואינטואיטיבי. הרעיון הוא שהכל מאוגד במקום אחד ונגיש דרך הדפדפן ובכך חוסך שימוש בתוכנות רבות ומגוונות. טופטיר הפכה למרכז הפיתוח של SAP בישראל (SAP Labs) ועם השנים הגדילה את מצבת העובדים שלה במאות אחוזים.
במקביל, הפורטל של SAP הפך עם הזמן לחבילת תוכנה מלאה בשם SAP NetWeaver. פלטפורמה זו כוללת בתוכה מספר מודולים שיחד מציעים תשתית רבת עוצמה להפעלת תוכנות ארגוניות שונות. בין השאר כוללת הפלטפורמה

  • שרת J2EE – SAP J2EE Engine
  • פורטל ארגוני – SAP Enterprise Portal
  • מערכת דוחו"ת BI – SAP BW
  • מחולל אפליקציות ויזואלי – Visual Composer
  • סביבת פיתוח ויזואלית – SAP NetWeaver Studio מבוססת אקליפס

פיתוחים מעניינים במסגרת התפקיד
בשנתיים הראשונות התמקדתי בגרסה הראשונה של הפורטל שנקראה EP 5. גרסה זו היתה מבוססת ברובה על הפלטפורמה שפותחה בטופטיר תוך שימוש בטכנולוגיות מיקרוסופט: COM, IIS, ASP, VC++, ATL. המשימות הראשונות היו להפוך את הפורטל ממוצר של חברת סטארטאפ, למוצר שמתאים לסטנדרטים של SAP. הרבה עבודה נדרשה ובמשך שנתיים עמלנו על שחרור גרסאות משופרות. הדגש היה על ביצועים, עמידות, גלובליזציה ותמיכה בשפות מרובות, ותמיכה בפלטפורמות שונות ובעיקר Oracle מאחר והגרסה הראשונה רצה על SQL Server בלבד.
בשלב השני התחלנו לפתח את הגרסה החדשה של הפורטל – EP 6. גרסה זו התבססה כולה על פלטפורמת J2EE ולמעשה נכתבה מחדש מאפס. מרכז הפיתוח בישראל עשה מעבר מהיר לאנשי הפיתוח מC++ לJava. העובדים עברו קורסים מזורזים, גיוסים מאסיבים של אנשי ג'אווה ותחלופת עובדים טבעית הפכו מהר את החברה למרכז מבוסס ג'אווה לחלוטין. הצוות שלי היה אחראי בעיקר על פיתוח רכיבי התממשקות Connectors למערכות חיצוניות: Siebel, Lotus Notes, PeopleSoft  ועוד תוך שימוש בארכיטקטורת JCA.

בתי זיקוק

על החברה
בז"ן הינה בית הזיקוק הגדול בישראל ונסחרת בבורסה בשווי של מעל 5 מליארד ₪. החברה מספקת את מרבית מוצרי הנפט המזוקק לחברות האנרגיה בישראל.

פיתוחים מעניינים במסגרת התפקיד
בבז"ן קיימת מערכת SAP ERP ומערכות חיצוניות אחרות מבוססות טכנולוגיות שונות: ASP, J2EE, VB ועוד. במסגרת התפקיד תכננתי ופיתחתי מערכת ממשקים בין המערכות השונות בארגון מבוסס Web Services ותואם לארכיטקטורת SOA. התפקיד כלל הסבה של מערכות ישנות לפלטפורמות SAP J2EE, אינטגרציה בין מערכות שונות בארגון ופיתוח פיצ'רים חדשים במערכות תפעוליות בסביבת Oracle iAS וOracle JDeveloper.

פז ובתי זיקוק אשדוד

על החברה
בשנת 2006 רכשה חברת פז את בתי זיקוק אשדוד במסגרת מהלך הפרטה של הממשלה תמורת 3.2 מליארד ₪. הרכישה יצרה אתגר עצום למחלקת הIT בשני מובנים:
הפרדת מערכות המידע של בתי זקוק חיפה ובתי זיקוק אשדוד שעד אז פעלו כיחידה אחת
אינטגרציה של מערכות המידע של בז"א עם אלו של חברת פז

על התפקיד
במסגרת התפקיד ייעצתי לחברת פז ולקחתי חלק בהתאמה, הגירה ואינטגרציה של מערכות אשר "ירשו" מבתי זיקוק אשדוד. התפקיד כלל פיתוח בJava/J2EE על פלטפורמת Oracle JDeveloper ושרתי Oracle AS, ניתוח ואפיון המערכות, פיתוח ממשקים ואינטגרציה עם מערכות פז הקיימות ובעיקר SAP R3.

הנוער העובד והלומד

על הארגון
תנועת הנוער "הנוער העובד והלומד" הוא תנועת הנוער השלישית בגודלה בישראל וכוללת עשרות אלפי חניכים. מערכות הIT של התנועה מתאפיינות בזמני פיתוח קצרים ובהורדת עלויות ע"י פיתוחים פנימיים הנעשים ע"י אנשי מקצוע בתוך הארגון.

על התפקיד
במסגרת התפקיד ביקשנו לפתח ולהקים מערכת ניהול מבוססת WEB שתסייע בניהול משאבי ארגון. המערכת אופיינה ע"י אנשי הארגון וכללה מודולים שונים. על מנת לצמצם בעלויות, שימשתי כיועץ חיצוני במשרה חלקית וסייעתי להכשיר אנשים בתוך הארגון תוך שאני מספק את הארכיטקטורה ואת רכיבי הליבה בעוד שעובדי הארגון מפתחים את שאר החלקים. בין השאר פיתחתי שכבת גישה לDB, מערכת ניהול משתמשים, גישה למסמכים ועוד. המערכת פותחה על שרתי MS IIS תוך שימוש בASP.NET וC# ובבסיס נתונים MySQL.

אדוונטק

על החברה
אדוונטק היא חברת IT ישראלית המונה ארבעה חטיבות עיקריות: SAP, Oracle, Microsoft, Java. החברה מעסיקה כ300 עובדים ופועלת במגזרים שונים.

על הפרוייקט
במסגרת התפקיד הדרכתי שלושה קורסים רשמיים של חברת SAP באיסטנבול, טורקיה.
הקורסים עסקו בהקמה, ניהול ופיתוח בשרתי SAP J2EE Server וניהול תצורת Java בסביבת SAP NetWeaver.

GigaSpaces

על החברה
GigaSpaces הינה חברת סטארטאפ מובילה בתחום הGrid Cache ומפתחת מוצר לשיפור ביצועים במערכות מבוססות Java. המוצר של גיגהספייסס הינו טכנולוגיה מתקדמת שמאפשרת שמירה ואיחסון של אובייקטי Java בזמן ריצה על שרתים שונים בGrid תוך שימוש במשאבים פנויים לפי הצורך.

על הפרוייקט
במסגרת התפקיד פיתחתי קוד בC# על מנת לאפשר העברה וסיריאליזציה של אובייקטי Java מהמערכת של GigaSpaces למערכות .NET ובחזרה. הפיתוח היה בדגש על ביצועים ותמיכה בMulti Threading.

מכללת אינטרביט

על החברה

InterBit הינה המכללה המובילה בישראל ללימודי Java ומכהנת כנציגה הרשמית של SUN בישראל. המכללה מעבירה קורסי ג'אווה בחברות ההי-טק המובילות בישראל בכל תחום אפשרי בJava וכמו כן מתמחה במוצרי קוד פתוח אחרים כגון: PHP, Linux וכו.

על התפקיד
במסגרת התפקיד הדרכתי בקורסי ג'אווה שונים בינהם: Basic Java Programming, Advanced Java, Extreme Java, Developing Eclipse Plug-ins ועוד. הקורסים כללו נושאים מגוונים כגון: Multi Threading, Performance, Memory Management, Design Patterns, JDBC, RMI, JNI, JMX. בין השאר הדרכתי קורסים פנימיים ובחברות: אמדוקס, קומברס ואחרות.

דנשיר מערכות

על החברה
דנשיר מערכות הינה חברת תוכנה המתמחה במתן שירותי IT ומערכות מידע בסביבות מגוונות. לחברה נסיון רב במערכות SAP ופיתוח ויישום ERP והינה שותפה עסקית של SAP.

על התפקיד
במסגרת התפקיד ניהלתי את קבוצת Java & NetWeaver בחברה. התפקיד כלל גיוס וניהול של מפתחי ג'אווה לקבוצה, שווק ומכירות מול לקוחות החברה וגיוס פרוייקטים חדשים, תכנון פרוייקטים בJava ובסביבות SAP Portal אצל לקוחות החברה. בין הפרוייקטים שביצעתי במסגרת החברה:

פיתוח פורטל ארגוני באוניברסיטת חיפה
פיתוח מערכת לדיווחי שעות עבור הסגל הזוטר באוניברסיטת חיפה. אוניברסיטת חיפה מעסיקה אלפי עובדים זמניים בשנה (לעיתים כאלה שעושים עבודה חד-פעמית כגון בדיקת מבחנים או סיוע למחקר). כל עובד מחוייב להגיש דו"ח שעות מפורט שעובר שרשרת אישורים ומוזן למערכת הSAP. המערכת החדשה פותחה בJava/J2EE על בסיס SAP Portal (תוך שימוש בWebDynpro) ומאפשרת לכל איש סגל לדווח שעות דרך מערכת WEB פשוטה וקלה לשימוש. המערכת מנהלת שרשרת אישורים דרך SAP Workflow כך שכל טופס עובר את אישור הדרגים השונים בארגון דרך הSAP.

פיתוח מערכות שונות בחברת נטפים
בחברת נטפים ניהלתי את מערכת הSAP Portal ופיתחתי מספר אפליקציות Java בטכנולוגיית WebDynpro. המערכת של נטפים כוללת עשרות אפליקציות הכתובות בJava ונחשבת למתקדמת ומושקעת.

פיתוח מערכת ניהול בחברת CNW
CNW הינה חברת בלדרות אקסקלוסיבית המתמחה במשלוחים בינלאומיים רגישים הדורשים זמני שילוח קצרים במיוחד. לחברה מערכת ייחודית לתמחור וניהול המשלוחים שפותחה כולה בJava/J2EE על שרתי JBoss. המערכת מבוססת על טהרת הקוד הפתוח: שרתי JBoss, בסיס נתונים MySQL, ותצורת J2EE קלאסית: שכבת UI שנכתבה בServlets/JSP, שכבת מידע ממומשת באמצעות EJB.

על התפקיד
במסגרת התפקיד ניהלתי את צוות הפיתוח של החברה והובלתי את הארכיטקטורה ואת אסטרטגיית הIT של הארגון. בתקופה זו הכנסתי סטנדרטים חדשים בחברה: נהלים לאבטחה וגיבוי, ניהול תצורה, ובקרה על הקוד. בנוסף התחלנו להגר את שכבת הUI ממשקי JSP עם עיצוב לא מיושן וקוד "ספגטי" לשכבת JSF תוך שימוש בספריית IceFaces. בנוסף הובלתי את פיתוחה של מערכת סינכרון המבוססת JMS ומסנכרנת בין שרתי החברה השונים המוצבים בעולם.

אינפורמטיקה

על החברה
אינפורמטיקה הינה חברה אמריקאית המובילה בפיתוח כלי ETL. מוצר הדגל של החברה PowerCenter מאפשר הטענה של מידע ממקורות שונים: בסיסי נתונים, מערכות ERP, Web Services, מסמכים, קבצים וכו', עיבוד המידע והעברתו למערכות אחרות.
בשנת 2008 רכשה אינפורמטיקה את חברת איטמפילד הישראלית תמורת 55 מליון דולר. חברת ItemField פיתחה מנוע המאפשר להמיר קבצים ומידע בפורמטים שונים בדגש על unstructured data. למשל: סריקה של מסמכי word או Excel והפיכתם למידע טבלאי מובנה. Parsing של קבצים בינאריים בעלי פורמט משתנה ועוד. המוצר מוטמע במוצרים אחרים תחת הסכמי OEM עם חברות כמו: SAP, IBM.

על התפקיד
במסגרת התפקיד לקחתי חלק בפיתוח מוצר חדש בשם Data Exchange. מוצר זה מאפשר לקבל הודעות מארגונים וחברות חיצוניות, להמיר אותם לפורמטים המתאימים ולשמור אותם במערכות הפנים ארגוניות. המוצר מהווה את פלטפורמת הB2B של אינפורמטיקה ובין לקוחותיו העיקריים נמצאים כמה מן הבנקים הגדולים בעולם. בצוות הDX פיתחתי את הממשקים בין שרתי הDX לכלי אינפורמטיקה האחרים: PowerCenter. המערכת פותחה בJava תוך שימוש בHibernate, SPRING, בסיס נתונים Oracle, JMS, וטכנולוגיות WEB כמו Tomcat וGWT.

אודות שלמה שוורץ

shlomo_schwarcz

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

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

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

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