2010


30
דצמ' 10

משטרת ישראל – יש גבול למה שצריך לעשות במדיה חברתית (או צריך להיות אחד כזה)

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

היום, לעומת זאת, המשטרה לדעתי טעתה ועברה את הגבול:

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

אבל זה ממשיך בתגובות: "יענו עכשיו בכלא ישימו אותו עם עציר ערבי שיושב כמעט 5 שנים בלי סקס ויפיל לו כל חצי שעה ת'נקע 7 במקלחת " אתה רוצה לראות בולבול של בדואי …?! " – נכון לזמן זה, לפני 52 דקות (!) ואף אחד לא העיף את זה מהקיר..

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

רק דעתי.


22
דצמ' 10

קואניי (קואן) פייטון

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

הקואנים של פייטון (רעיון שבמקור נלקח מרובי למעשה) הם רשימה של 287 קואנים, או למעשה, Unit Test שנכשלים, והמטרה שלהם היא ללמד את השפה דרך הידיים – כדי לעבור את המבחן עליכם "לתקן" את הבדיקות שתעבורנה, וכך אתם לומדים את השפה. רעיון טוב, לא?

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

בהצלחה!


5
דצמ' 10

שימוש בwireshark תחת מקינטוש Snow Leopard

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

משום מה תחת הגרסה האחרונה של המק, snow leopard, הוא אינו מצליח לגלות interfaces – את כרטיסי הרשת למעשה. מתברר שבצורה דיפולטיבית אין למשתמש גישה ישירה אליהם. כדי לאפשר את הגישה פתחו חלון console וכיתבו:

sudo chown {your account name} /dev/bpf*

27
נוב' 10

כיצד להתקין facebook places באייפון בישראל

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

שלב ראשון: לאפשר vpn בטלפון שלכם:

  1. לכו ל settings->general->network->vpn
  2. הוסיפו vpn עם הפרטים הבאים:
  • קודם כל עיברו לIPSec בטאב למעלה
  • תיאור (description):   Hotspotshield
  • Server: 68.68.107.101
  • Account: dqffmr
  • Password: dqffmr
  • Group Name: hss
  • Secret: hss

אני לא בטוח מה השמות בעברית, אבל הסדר זהה.

לחצו על Save וחזרו לדף הקודם.

שלב שני: פייסבוק

בכל פעם שתרצו להשתמש בפלייסס, לחצו על Settings->VPN (הפעם התפריט הזה מאופשר מהר יותר) – הכנסו לפייסבוק והופה! עובד!

לאחר השימוש מומלץ לכבות את הVPN.

הערה:

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


5
נוב' 10

התקנה לוקלית של מסמכי django במערכת windows

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

אחת הפעמים הללו קרתה היום בבוקר, כשרציתי להתקין את המסמכים (documentation) של דג’נגו לוקלית בלפטופ שלי לקראת טיסה לחו”ל בה הרשת לא תהיה זמינה. הפרטים ברשת היו די ברורים: התקן דג’נגו והרץ make על הMakefile שבספריית הDOCS. כמובן, אין make בהתקנה רגילה של ווינדוס, וכאן הדברים מתחילים להסתבך. אז הנה הסבר צעד אחר צעד אם גם אתם נתקלים בבעיה.

אני מניח שיש לכם python ו-django מותקנים במערכת.

המטרה שלכם – להפוך את ספריית הdocs המותקנת בדג’נגו לספריית html או PDF, עם קישורים, תמונות וכו.

הפורמט של הספרייה הזו הוא sphinx, אבל כמו שהאתר אומר, השיטה הקלה ביותר להתקין ספינקס היא ע”י שימוש בפקודה

easy_install -U Sphinx

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

אם יש לכם windows 7 ב64 ביט, יש באג בהתקנה של פייטון. עליכם לערוך בצורה ידנית את הregistry: הוסיפו את ספריית הפייטון שלכם במפתח הזה: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.6\InstallPath

(כמובן שגירסת הפייטון תלויה במה שיש לכם).

חזרו לcommand, והתקינו את ספינקס (כאמור: easy_install –U Sphinx).

עכשיו, מתוך הספרייה הראשית של דג’נגו, הקישו (כדי ליצור html):

sphinx-build -b djangohtml docs html/


30
אוק' 10

בניית מערכת שותפים ואינטגרציות לאתר–למה, מתי ואיך

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

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

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

בסטארטאפ, לרוב תעשו שיתופי פעולה מאחת הסיבות הבאות:

  1. יתרון תחרותי – השלמת הסיפור (use case)
  2. הרחבת שווקים וערוצים
  3. רגל בדלת – הפיכה לחלק בלתי פריד בחיי המשתמש

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

יתרון תחרותי

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

הרחבת שווקים וערוצים

כיצד אתם מגיעים ללקוחות שלכם? איפה הם נמצאים, איפה נמצא השיווק שלכם ואיפה הוא מתרכז? ישנן אינטגרציות מסויימות שאינן משלימות סיפורים, אבל מאפשרות לכם להתחבר לערוץ חדש. שווקי האפליקציות הרבים הם דוגמא לכך: בעבודה מינימלית אפשר להתחבר לGoogle App Market, או SalesForce AppExchange. החנות של אפל אינה פתרון כזה, משום שאי אפשר ללכת בלעדיה (בצורה חוקית). זהו חיזוק לגוף השיווק שלכם.

רגל בדלת

לפעמים שיתוף פעולה מאפשר לכם להיות שם בשביל הלקוחות שלכם בצורה כזו שעלות השינוי בעתיד תהיה גבוהה מדי.זה אולי לא פתרון פופולרי אבל הוא עובד. עלות שינוי ממוצר טוב היא תמיד גבוהה – אפילו אם העלות פסיכולוגית בלבד. התחלתי להשתמש בTeetDeck כשהם התחילו לתמוך בקבוצות. היום כולם עושים את זה, אבל אלא אם תהיה סיבה אחרת מאוד טובה, אני אשאר עם התוכנה הזו. גם החיבור שלנו עם intacct הוא כזה: ברגע שכל המידע עובר חלק לגוף הכספים אצל הלקוחות, יהיה קשה יותר לשנות – אם מנהלי הפרוייקטים יבקשו להחליף אותנו בתוכנה מתחרה הם יצטרכו אישור של אנשי הכספים משום שאלו עובדים בנוחות רבה עם תוכנת Intacct ומקבלים נתונים באופו מהיר ושותף מקלאריזן. זהו חיזוק לגוף הCustomer Success שלכם.

לסיכום

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


30
יולי 10

מבחן פולי קפה TO.Mo.Ca מאתיופיה

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

מחיר הקפה: לא ניתן להשיג בארץ.

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

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

גוף: קצת מיימי, אבל בגדול מאוד מאוזן.

טעם: מריר ושוקולדי, כמעט כמו לשתות שוקולד מריר מאוד עם תוספת מיים ופאנץ'’ של קפאין.

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


27
יולי 10

התנהלות וקביעת עדיפות לטיפול בבעיות בזמן קריטי

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

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

הנה עוד כמה נקודות שתעזורנה לכם לעבור את התקופות האלה:

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

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

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

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


17
יולי 10

שירות בעננים – מדוע לבחור פתרון SaaS לעומת פתרונות מיושנים יותר?

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

בשיחה עם חבר שמקים בימים אלו את הסטארטאפ שלו, אחרי שנים של כיהון כסמנכ”ל מכירות בסטארטאפ מצליח אחר (יש לו כבר מימון לחברה החדשה, תודה :) ), הוא הסביר לי בין השאר על מערך הIT של האירגון הקטן שלו. זוהי חברה בראשית דרכה, עם שני עובדים, 3 ספקים חיצוניים, 2 סטודנטים שעובדים מצרפת בתחומים שונים, וכמה חברים שעוזרים בכמה משימות שונות ומשונות. בלי הבנה טכנולוגית עמוקה אבל עם המון הגיון טוב ופרקטיות, הוא מוצא את עצמו לאט לאט עובר למערך ענן (cloud) ומשתמש בשירותי תוכנה כשירות (SaaS) – וענין אותי התהליך שהוא עבר והיתרונות שהוא מוצא ומגלה. אספר בכמה מילים את את הלקחים הראשוניים שלו, אבל אתחיל בהסבר קצר:

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

שירותי תוכנה כשירות – SaaS – Software as a Service – הוא השם לשירותי תוכנה עצמם שמספקות חברות חיצוניות, לעיתים קרובות ע”י שימוש בענן, כשכל אירגון מקבל למעשה שירות מלא (IT, פיתוח, עידכונים, שירות וכו) במחיר חודשי ולא בהתקנה חד פעמית, וכך גם נחסך הצורך באנשים המכירים את הפרטים הטכניים של התוכנה. שירותים כאלה שכולנו מכירים הם gmail, לדוגמא – בעוד שבעבר כל הדואר ישב בתוכנה מקומית במחשב, עכשיו הדואר יושב בתוכנה שהיא שירות (gmail), שיושבת על הענן של גוגל.

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

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

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

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

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

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

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

  • חיבור לשירותים נוספים – בהמשך, החברה תזדקק לשירותי חשבונאות מתקדמים. כשכל זמן העבודה, התימחורים וההוצאות יגיעו לתוכנת החשבונאות מקלאריזן, ונתוני המכירות יגיעו מsalesforce, החברה לא תזדקק לכפילות מידע, הזמן של הכנסת הנתונים יקטן והדיוק יעלה. כמו כן, החברה תוכל לקבל שירותים חיצוניים לכל דבר שתרצה – משום שכל ספק חיצוני כמו רואה חשבון או עובד מרחוק יכול פשוט להכנס לענן ולעדכן את המידע שצריך.
  • קבלת Added Value – ישנם סוגים שונים של יתרונות שרק תוכנת SaaS יכולה לספק. בקלאריזן לדוגמא, ישנה יכולת שיתוף של ספקים חיצוניים במשימות היום יומיות שלנו בחשיפה מאובטחת בדיוק לפי איך שאנחנו והספקים החיצוניים רוצים: אנחנו לא חושפים את כל המידע על הפרוייקט שלנו, ומצד שני, כשיש לנו תלות בספק חיצוני, אנחנו יכולים לבצע תלות על אבן דרך (milestone) בפרוייקט שלהם, ללא צורך לדעת או לראות את תת המשימות שמרכיבות את האבן דרך הזו. אם הם מקדימים או מאחרים, אנחנו יודעים את זה ומבינים מידית מה ההשפעה על האירגון שלנו, במיוחד אם הם נמצאים על הcritical path. אנחנו קוראים לזה sense and respond בקלאריזן – אבל יכולת השיתוף הזו אפשרית רק בתוכנות השוכנות בענן כלשהו.
  • הרחבת הגירסה: בגרסאות העתידיות של קלאריזן נאפשר אפליקציות חיצוניות שמוסיפות ערך נוסף בתוך ניהול העבודה, בצורה דומה למה שsalesforce עושים, או לgadgets שגוגל מציעים. בצורה כזו ניתן בקלות להרחיב אף יותר את היכולות של התוכנה שלך. עד כאן אין יתרון לענן – גם לתוכנות שולחניות יש הרחבות, אבל היכולת לבדוק הרחבה בקלות ובמהירות, להתקין ולהסיר בלי עזרה מיוחדת של איש מקצוע או איש IT, היא הכוח של הSaaS. אם בעבר הייתם זקוקים לאיש מקצוע שיגיע למשרד להתקין ולהכין, היום גם אתם יכולים לבצע את השינוי תוך דקות מספר.

האם החברה שלכם משתמשת בשירותי ענן? במה בחרתם, ומה היו הסיבות?


19
יוני 10

וורדפרס במצב עדכון (maintenance).. מה עושים עכשיו?

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

 

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

 

לא משנה לאיזה דף תגשו באתר, תקבלו את ההודה הבאה:

“Briefly unavailable for scheduled maintenance. Check back in a minute.”

 

עליכם להכנס לספריה הראשית של וורדפרס בעזרת תוכנת ftp כלשהי (מותקנת אצלכם או דרך ספק האיחסון שלכם) ולמחוק קובץ שנקרא “.maintenance” (שימו לב לנקודה התחילת הקובץ) – הקובץ הזה מוגדר כבלתי נראה, אז אם אינכם רואים אותו עליכם להפעיל את היכולת הזו בתוכנה שלכם. אם אתם משתמשים בתוכנה הפופלרית filezilla, חפשו את ההגדרה תחת Server->Forece Showing Hidden files.

 

בהצלחה!