להשתמש ב-TextMate בשביל הודעות Commit של Git


אני עובד עם Textmate ועם Git מאז שיש לי מק ומאז שהתחלתי לעבוד עם Ruby On Rails.

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

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

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

ראשית, צריך להורות ל-Git להשתמש ב-TextMate בשביל זה, עושים את זה על ידי ה-Command Line – כך:

git config --global core.editor "mate -w"

לאחר מכן, את הודעות הקומיט מבצעים כך:

git commit -a --amend

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

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

ריבוי מילים בפלקס (או… מה שמובן מאליו למתכנתי רובי און ריילס)

SingularPluralSort.pdf.00

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

בעצם זה נשכח, עד השבוע.

השבוע קיבלתי באג במערכת של לקוח שאומר שכאשר הוא בוחר מודול למחיקה הוא רואה (are you sure you want to delete the selected module) והוא רואה את אותה ההודעה בדיוק כאשר הוא בוחר מספר מודולים.

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

 

var module:String = "module";

			if(list.selectedItems.length > 1)
				module = "modules";

			Alert.show(StringUtil.substitute("are you sure you want to delete the selected {0}", module);

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

מה עשיתי?
1. חיפשתי בגוגל ומצאתי שמישהו עשה porting לקוד של מחלקת Pluralization מריילס ועשה אותה בas3
2. שכתבתי את הקוד וחשפתי החוצה פעולה אחת בלבד

הנה הקוד המלא (לשימושכם החופשי):

		public function PluralizationHelper()
		{
		}

		static:{
			PluralizationHelper.initPluralization();
		}

		private static var pluralWords : Array =
			[
				[/$/, 's'],
				[/s$/i, 's'],
				[/(ax|test)is$/i, '$1es'],
				[/(octop|vir)us$/i, '$1i'],
				[/(alias|status)$/i, '$1es'],
				[/(bu)s$/i, '$1ses'],
				[/(buffal|tomat)o$/i, '$1oes'],
				[/([ti])um$/i, '$1a'],
				[/sis$/i, 'ses'],
				[/(?:([^f])fe|([lr])f)$/i, '$1$2ves'],
				[/(hive)$/i, '$1s'],
				[/([^aeiouy]|qu)y$/i, '$1ies'],
				[/(x|ch|ss|sh)$/i, '$1es'],
				[/(matr|vert|ind)ix|ex$/i, '$1ices'],
				[/([m|l])ouse$/i, '$1ice'],
				[/^(ox)$/i, '$1en'],
				[/(quiz)$/i, '$1zes']
			];

		private static var singularWords : Array =
			[
				[/s$/i, ''],
				[/(n)ews$/i, '$1ews'],
				[/([ti])a$/i, '$1um'],
				[/((a)naly|(b)a|(d)iagno|(p)arenthe|(p)rogno|(s)ynop|(t)he)ses$/i, '$1$2sis'],
				[/(^analy)ses$/i, '$1sis'],
				[/([^f])ves$/i, '$1fe'],
				[/(hive)s$/i, '$1'],
				[/(tive)s$/i, '$1'],
				[/([lr])ves$/i, '$1f'],
				[/([^aeiouy]|qu)ies$/i, '$1y'],
				[/(s)eries$/i, '$1eries'],
				[/(m)ovies$/i, '$1ovie'],
				[/(x|ch|ss|sh)es$/i, '$1'],
				[/([m|l])ice$/i, '$1ouse'],
				[/(bus)es$/i, '$1'],
				[/(o)es$/i, '$1'],
				[/(shoe)s$/i, '$1'],
				[/(cris|ax|test)es$/i, '$1is'],
				[/(octop|vir)i$/i, '$1us'],
				[/(alias|status)es$/i, '$1'],
				[/^(ox)en/i, '$1'],
				[/(vert|ind)ices$/i, '$1ex'],
				[/(matr)ices$/i, '$1ix'],
				[/(quiz)zes$/i, '$1']
			];

		private static var irregularWords : Array =
			[
				['person', 'people'],
				['man', 'men'],
				['child', 'children'],
				['sex', 'sexes'],
				['move', 'moves']
			];

		private static var uncountableWords : Array =
			[
				'equipment', 'information', 'rice', 'money', 'species', 'series', 'fish', 'sheep'
			];

		private static function makePlural (singular : String) : String
		{
			if (uncountableWords.indexOf(singular) != -1)
				return singular;

			var plural : String = new String();
			for each (var item : Array in pluralWords)
			{
				var p : String = singular.replace(item[0], item[1]);
				if (p != singular)
					plural = p;
			}
			return plural;
		}

		private static function makeSingular (plural : String) : String
		{

			if (uncountableWords.indexOf(plural) != -1)
				return plural;

			var singular : String = new String();
			for each (var item : Array in singularWords)
			{
				var s : String = plural.replace(item[0], item[1]);
				if (s != plural)
					singular = s;
			}
			if(singular == "")
				return plural
			else
				return singular;
		}

		[Bindable(event="pluralizationChangedEvent")]
		public static function pluiralize(count:int, word:String):String
		{
			if(count == 1)
				return makeSingular( word );

			return makePlural( word );
		}

		static private function initPluralization() : void
		{
			for each (var arr : Array in irregularWords)
			{
				pluralWords[pluralWords.length] = [arr[0], arr[1]];
				singularWords[singularWords.length] = [arr[1], arr[0]];
			}
		}
	}

איך מפעילים את הקוד מתוך האפליקציה? ובכן, כך:

PluralizationHelper.pluiralize(count, 'custom field')

הקוד הזה הוא חלק מספרייה שאני משחרר שהיא אוסף Helpers כלליים לאפליקציות פלקס.
את קוד המקור של כול הספרייה (שכרגע מכילה רק את הקלאס הזה אבל תתעדכן בהמשך) אפשר למצוא בgit בקישור הבא
http://github.com/KensoDev/Flex-Generic-Helpers

תהנו!

אם יש שאלות, תרגישו חופשי

תאוריית החלון השבור – איך זה קשור לפיתוח תוכנה?

חלון שבור

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

מכירים את תאורית החלון השבור? לא? סבבה, בשביל זה אני כאן – בואו נדבר קצת.

הקדמה – תאוריית החלון השבור

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

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

החוקרים לקחו מכונית יפה לכל הדעות, טובה ואף יקרה – לצורך הדוגמא, מכונית של חברת יגואר. הם החנו אותה בשכונת Bronks ב-New York וצפו בה מהצד. במשך מספר ימים עברו ליד המכונית אלפי אנשים – אף אחד לא נגע בה, לא שריטה ולא שבר, המכונית נשארה כשם שהייתה, בדיוק כפי שהם השאירו אותה.

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

בעקבות הניסוי החוקרים פיתחו את תאוריית החלון השבור, בואו ונבהיר אותה או לפחות ננסה.

בניין מגורים – חלון שבור

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

תיאורית החלון השבור - בניין מגורים

תיאורית החלון השבור - בניין מגורים

אני יודע מה אתם חושבים עכשיו (אני גם קורא מחשבות בזמני הפנוי)…

מה זה קשור לפיתוח תוכנה ואיך זה נוגע לי כמפתח בחיי היומיום?

כן, הכותרת שברה שיאי אורך :-)

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

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

קוד מקור לדוגמא

קוד מקור לדוגמא

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

אילוצים או תירוצים?

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

אבל אם נסתכל אחד לשני (ולעצמנו) בעיניים אנחנו בעצם יודעים שאלה תירוצים ולא סיבות.

מה אפשר לעשות?

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

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

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

לסיום, אני רוצה לצטט את Uncle Bob Martin (ברשותכם כמובן)

No matter who. No matter what. No matter when. Short term.Long term. Any term. Writing good code is ALWAYS faster than writing bad code.

Refactoring should never appear as a task on a schedule, Keeping code clean is just something you do all the time

כרגיל, אשמח לתגובות.

הטעויות הכי נפוצות (וגדולות) בפיתוח אפליקציות פלקס

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

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

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

1. שימוש בflex כדי לבנות אתרי אינטרנט או אפליקציות מדור ישן

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

אני זוכר, בתור ילד צעיר למדתי קראטה, with great power comes great responsibility, אמצו את זה כאשר אתם ניגשים לפתח אפליקציה. אם אין לכם אפליקציה שדורשת ויזואליות מסוימת, אנימציות, עבודה עם datasets גדולים וכו', עדיף שתשתמשו בטכנולוגיות אחרות כמו html, css ואפילו פלאש.

Flash this not that

Flash this not that

אפשר לראות פוסט באנגלית על זה כאן

מקור התמונה The Flash Blog

2. האטת האפליקציה עד כדי זחילה על ידי שימוש ביותר מדי containers

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

השקף הזה מדבר על ריבוי containers. הרבה אנשים שמגיעים מhtml לתוך עולם הפלקס (וזה קורה המון) לא מבינים שcontainer  בפלקס הוא component בפני עצמו שיש מאחוריו עשרות (לעיתים מאות) חישובים של גודל, מיקום, מיקום ילדים, גודל ילדים. ועוד יותר גרוע מזה, ולידציות וinvalidations.

מפתחים לא תמיד מבינים את מחזור החיים של container ולכן עושים שימוש במספר כאלה מקוננים אחד בתוך השני, באפליקציות dashboard ראיתי לפעמים 15-20 רמות של קינון. זה פשוט נורא, אפליקציה עם המון containers תצרוך כמות כפולה ומשולשת של זכרון וכול תזוזה תקח שניות רבות וחווית השימוש תפגם.

אפשר לראות כאן צילום מסך של תחקיר שעשו חברים בקהילה מאתר Inside RIA

צריכת זכרון כאשר יש יותר מדי Containers

צריכת זכרון כאשר יש יותר מדי Containers

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

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

יותר מדי container באפליקצית flex

יותר מדי container באפליקצית flex

הדרך הראשונה

והקוד:

 <Application layout="absolute">

     <HBox width="100%">

         <Button label="Left"/>

         <Spacer width="100%"/>

         <Button label="Left"/>

     </HBox>

 </Application>
יותר מדי container באפליקצית flex

יותר מדי container באפליקצית flex

שימו לב שיש לנו כאן מספר containers, רובם מיותרים, סבב התיקונים הראשון ועכשיו האפליקציה שלנו נראית כך

הקוד שלנו נראה כך:

 <Application layout="horizontal">

     <Button label="Left"/>

     <Spacer width="100%"/>

     <Button label="Left"/>

 </Application>

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

מספר container נכון באפליקצית flex

מספר container נכון באפליקצית flex

הטיוב האחרון שלנו נראה כך:

והקוד נראה כך:

 <Application layout="absolute">

     <Button label="Left" left="5"/>

     <Button label="Left" right="5"/>

 </Application>

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

3. שימוש בXML

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

XML לא רק לוקח יותר זמן לפרסר אלא לוקח יותר זמן להעביר על הwire ויכול לעלות המון כסף של BandWidth.

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

את האפליקציה הזו אפשר למצוא כאן

דוגמאות לסוגי העברת מידע בין Client לServer

דוגמאות לסוגי העברת מידע בין Client לServer

4. שבירת מוסכמות והרגלי גלישה באינטרנט

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

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

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

5. שימוש מוגזם באנימציות ומעברי עמודים

אני אהיה הראשון שאעמוד לימין הframework והיכולת שלו להתמודד עם משימות גראפיות כבדות, אבל אני גם אהיה הראשון לומר ש"My Account" לא צריך לעוף ב720 מעלות מתוך הקצה הימני של המסך, הוא לא צריך לשנות את הצבע שלו ולא צריך להזיז את הכפתור ב200 קמ"ש אחרי שלחצתי.

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

יודעים מה, כבר עשיתם את זה, תאפשרו למשתמש לכתוב את זה.

כנ"ל עם מוזיקה או Audio Effects.

6. לא לפתח סביבת פיתוח תומכת Craftsmanship או Agile או לא לפתח EcoSystem בכלל

זה נכון לכול טכנולוגיה, בין אם זה flex או אפילו Ruby on rails. לגשת ישירות לפיתוח מבלי להתחשב ולא להנהיג שיטות Tdd/Bdd, Unit Testing, Code Coverage וכו' זה פשוט לא אחראי, זה לא אחראי במיוחד באפליקציות פלקס מכיוון שכשלא עושים את זה, צריכים לבדוק את הכול דרך הUI, לחכות לקומפיילר שירנדר את האפליקציה בכול פעם, זה בזבוז זמן ומשאבים אדירים.

אל תשתמשו בQA כמכונה לאיתור באגים בUI, תבדקו את האפליקציה שלכם, היום עם פלקס 4 יש כול כך הרבה שיטות ויכולות שזה פשוט פשע לא לעשות את זה.

הנה כמה:

FlexUnit

FlexMonkey

תפתחו שיטות עבודה איכותיות שמעודדות בדיקות, מעודדות Craftsmanship, מעודדות Clean Code ואחריות מפתחים.

7. לא לעשות שימוש בBuild Machine ובContinuous Integration

היות ואפליקציות Flex עוברות קומפליציה, כלומר מקוד מקור לאפליקציה סגורה, קובץ SWF שיטת הpublish צריכה להיות כזו

תהליך פיתוח ומעבר נכון לProduction

תהליך פיתוח ומעבר נכון לProduction

מה זה אומר בעצם?

זה אומר במפתח עושה Commit לקוד שלו, לתוך מכונה יעודית, במקרה הזה עדיף לעשות שימוש בGIT כי אז הוא יכול לעשות local commits וpush רק כשהוא בטוח שיש אצלו הכול.
המפתח כמובן בודק את הקוד שלו, כך שקוד שנכנס למכונה הוא קוד שעבר בדיקות.
על המכונה הקוד עובד בדיקות נוספות, כדי לבדוק Integration של כול המפתחים, במידה וכול הבדיקות עוברות, הקוד מתקמפל לאפליקציה ועולה לאוויר (אם צריך)

יעיל נכון?

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

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

כרגיל, אשמח לשמוע את דעתכם.

תוכנה לבדיקת לינקים שבורים באתרים (Mac)

David Walsh כתב בבלוג שלו השבוע על תוכנה למקינטוש שכל כך שמחתי לראות שאמרתי שאני חייב לכתוב עליה גם, אבל כל הקרדיט על הגילוי הראשוני מגיע לו :-)

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

מה התוכנה?

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

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

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

לתוכנה קוראים Integrity והיא חינמית. אפשר להוריד אותה מכאן

הנה כמה צילומי מסך של התוכנה מתוך אתר היוצר.

IntegrityShot3.2Main

IntegrityShot3.2Options

LabelScreenshot

תהנו.

כרגיל, אשמח לתגובות

תכנות מונחה התנהגות ברובי און ריילס – חלק 2 (Screencast)

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

החלק השלישי יצולם ויעלה בימים הקרובים.

כרגיל, אשמח לתגובות שלכם

תוסף ל-Flash Builder 4 שמתכנתי פלקס חייבים לנסות

Screen shot 2010-10-03 at 8.02.59 PMאני מתכנת פלקס כבר 4 שנים בערך, מתוכן חצי שנה או אולי קצת יותר אני עובד עם Flash Builder 4.

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

אני מתכנן לצלם השבוע screencast על התוסף הזה עם כול מיני טיפים והוראות של איך עושים בו שימוש וממקסמים אותו עד הקצה, אבל בינתיים, כתבתי על הנושא פוסט באנגלית. אתם מוזמנים לקרוא אותו – Make your life easier with this Flash Builder 4 plugin

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