פשוט תי(רובי) פרק 3

היום בבוקר עלה הפרק השלישי בפודקאסט פשוט תי(רובי).

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

כול אחר מהפנליסטים חשף את הכלים שעוזרים לו, והיה דיון מאוד מעניין, על אף שהקלטנו את הפודקאסט ב8:00 בבוקר :-)

קישור לפודקסט

לינקים שימושיים למפתחים #1

פוסט ראשון בסדרה, בפוסטים האלה אני אפרסם לינקים שימושיים למפתחים (בעיקר למפתחי רובי און ריילס ומפתחי Web)

iAd Producer – למי שרוצה לקחת חלק ולפרסם iAds ברשת של אפל, אפל הוציאו Producer מיוחד שמאפשר ליצור מודעות כאלה בצורה של Wysiwyg והפלט של העורך הזה הוא Html5 וCss3 שכול המכשירים של אפל יודעים לקרוא, בינהם הiPhone וכמובן הiPad.

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

צילום מסך Git Tower

צילום מסך Git Tower

סיור באתר באמצעות jQuery – אמנם לאחרונה אני עושה שימוש בMootools בכול הפרויקטים החדשים שלי אבל זה Tutorial נחמד שמראה איך אפשר ליצור סיור באתר ולהניח Tooltips במקומות הנכונים עם הסבר של מה בדיוק החלק הזה עושה. לאפליקציות עם אינטראקציה רבה זה בהחלט יכול להיות מאוד שימושי.

סיור וירטואלי באתר

סיור וירטואלי באתר

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

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

MongoDB Gotchas - אם אתם משתמשים בריילס וב-MongoDB יש כאן טיפים יקרים מפז.

25 טיפים לVim – אוסף של 25 טיפים בין אם כפוסטים בבלוג או כסקרינקאסטים (שאני מאוד אוהב) לשימוש בVim.

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

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

חלון שבור

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

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

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

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

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

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

יעיל נכון?

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

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

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

האם כול המתכנתים צריכים להיות חברים פעילים בקהילה?

בד"כ בפוסטים שלי, אני נוהג לקבוע קביעות, להגות דעות, וכו'.

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

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

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

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

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

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

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

עכשיו לשאלה…

שאלתי היא: האם לדעתכם כול המתכנתים צריכים להיות חברים בקהילה הוירטואלית של המתכנתים בארץ?
האם כולם צריכים לכתוב בלוגים?
כולם צריכים להיות חברים פעילים בStackOverflow.com?
האם כולם צריכים להיות חברים בפורומים ולעזור למתכנתים אחרים?

אשמח לתגובות ולדיון…

כלים ושירותים בהם אני משתמש – חלק ב'

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

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

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

VSO Image Resizer

VSO Image Resizer-20081017-071709 מי מכם משתמש במצלמה דיגיטלית?

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

בטח גיליתם שהמשימה קשה והתמונות פשוט ענקיות הן בגודל והן במשקל שלהן.

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

התוכנה "מתלבשת" על הShell של חלונות (נבדק על כולן מXP ועד 7)

10-08-2009 00-21-39

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

לינק להורדת התוכנה אתם מבקשים בטח לא? הנה כאן

TeamViewer

TeamViewer_full

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

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

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

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

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

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

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

טופין אמיתי

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

SyncBack

syncback-logo

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

אז אני אכתוב חלק.

גיבבבבבבבבבבבבווווווווווויייייייייייםםםםםםםםםםםם!!!

מכירים את זה?

עושים את זה מספיק?

שקרנים!

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

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

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

חלון הגדרת פרופיל מתוך התוכנה:

10-08-2009 00-42-40

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

העתק – הדבק של קוד

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

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

השירות שאני הולך להמליץ עליו (חינמי גם הוא) הוא http://snipt.org/

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

אתם עושים Paste של הקוד שלכם לתוך התיבה, בוחרים את השפה ואת הTheme ומקבלים URL שאתם יכולים לשלוח לחבר שלכם.

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

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

10-08-2009 00-56-38