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

מיתוס #1 - רק אתרים גדולים יכולים להרוויח מפרסומות של גוגל

טעות בידכם! גם אתרים קטנים יכולים להרוויח מאדסנס. אמנם לא הרבה, אבל זה בהחלט יכול לכסות את הוצאות האכסון של האתר ולהשאיר קצת רווח בידיים. אתרים שלי מכניסים לי בממוצע 8-9$ בחודש, כשבאף אחד מהם אין יותר מ-40 כניסות ביום, ואין שום סיבה שגם אתם לא תרוויחו ככה.

מיתוס #2 - אתרים ישראליים מרוויחים פחות

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

מיתוס #3 - אין לי שליטה על מה שקורה במודעות

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

מיתוס #4 - הדרך היחידה להרוויח יותר היא להביא עוד תנועה

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

מיתוס #5 - אני לא יכול להרוויח יותר מדולר לאלף חשיפות

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

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

בהצלחה.

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

בגדול, אנחנו מדברים על הדגשים הבאים:

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

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

קוד סמנטי

שפת HTML כשמה כן היא - Hyper Text Markup Language - זו שפה שמתארת את התוכן. בדיוק כמו XML. אנשים אמנם יראו את התוכן שנמצא בתגית <p> בדיוק כמו בתגית <span>, אבל המשמעות של שתי התגיות הללו שונה לגמרי (הראשונה מצביעה על פסקה, והשנייה מצביעה על שום דבר ממשי) - המשמעות מתחילה להתקבל כשמישהו (או משהו) קורא גם את הקוד, ולא רק את מה שהוא אמור לייצג. מנועי חיפוש הם ה"משהו" הזה בדיוק - אנחנו צריכים להגיד להם מה כל דבר אומר - אם זה תוכן רגיל, הוא יהיה עטוף בתגיות <p>, כותרות יהיו אחד מה-<h>ים (h1, h2 וכו') תלוי בחשיבות הכותרת.

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

תאור התוכן

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

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

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

כתובת קצרה וקליטה

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

מבנה קישורים נכון

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

תוכן הוא המלך

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

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

בהצלחה.

אה, כן. נהניתם? תרשמו.

בשעה טובה ומוצלחת הוצאתי לאוויר את sir.co.il - אתר הכרויות חינמי.

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

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

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

אבל מה אני לומד מכל העסק?

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

1. להשיק לאט ובזהירות - המערכת יכולה להכיל באגים שפיספסנו. משתמשים שמסתובבים ברחבי האתר ומחפשים מה לעשות עם עצמם הם בהחלט גלאי הבאגים הטובים ביותר. רובם המכריע לא יטרח להגיד לנו על הבאג, אבל אם זה משהו ברמה של "השמיים נופלים ואני מקבל error 500" אז אפשר לראות את המקור לבאג בלוגים של המערכת.
2. לקרוא את הלוגים - אני ישבתי וגירדתי את פדחתי כשהיו לי בערך 50 משתמשים רשומים ואף הודעה לא עברה ביניהם. אחרי שהורדתי את הלוגים הבנתי שפשוט שכחתי לבדוק אם משתנה כלשהו מכיל תאריך לפני שבדקתי שהתאריך לא רחוק מידי מהיום. קריאה קבועה של הלוגים ובדיקה של המקור לשגיאות בצד שרת יכולה לפתור הרבה בעיות.
3. להקשיב לגולשים - המעט שטורחים להגיב ולהציע הצעות בדרך כלל נותנים הצעות מאוד טובות. כדאי להקשיב להם. כמובן שיש כמה כאלה, אבל רוב האנשים שמספיק נחמדים כדי להגיב שווים את זה.

אם נעשה את כל אלה, סביר להניח שהכל יסתדר באיזשהו שלב…

אני מקווה.

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

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

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

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

למי שמתעניין - שווה להירשם לבלוג שלו.

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

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

אז מיקרוסופט הציעה 44.6 מליארד דולר על יאהו. ומיד כולם קפצו להיכון כדי לראות מה יקרה…

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

גוגל מפחדים

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

יותר תחרות

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

יאהו תמשיך להתקיים

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

סיכום

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

ומי ירוויח מזה? אנחנו.

נתחיל בשאלה הבסיסית:

מה זה רובי?

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

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

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

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

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

מה זה ריילס?

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

הגישות המנחות את המערכת הן:

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

קצת פרטים טכניים

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

בנוסף, ריילס מציגה רשימה עצומה של עזרים - כל מיני קודים מקוצרים שמקלים על חיינו ביצירת כל דבר החל מלינקים ותמונות וכלה ביישום מערכות ajax בעצמאות ספריות javascript כמו prototype ו-scrip.aculo.us.

עוד קצת דברים מגניבים

• ActiveRecord - זוכרים שאמרנו שכל דבר ברובי זה אובייקט, וכל פונקציה זה method? בעצמאות חבילת ActiveRecord כל הגישה למסד הנתונים מתבצעת בדיוק כך - האובייקט הוא שם הטבלה, וה-method הוא השדה. כלומר - User.name יגש לטבלאת users ויוציא ממנה את שם המשתמש שנבחר. למעשה, רוב ההתעסקות עם sql נמנעת מאיתנו - אלא אם כן יש משהו מסובך שלא ניתן לבצע, וגם אז אחרי כן ממשיכים להתייחס למידע כאל אובייקטים.
• ActionMailer - מאפשר לשלוח דוא"ל בצורה מאוד מאוד פשוטה
• ActiveSupport - אוסף של פונקציות שמטרתן היא לגרום לחיים שלנו להיות הרבה יותר פשוטים. החל מהפיכת מילים מלשון יחיד ללשון רבים (רק באנגלית, לצערינו) דרך המרות של אובייקטים לסוגים אחרים, מתודות שמפשטות את הגישה לתאריכים ושעות ועוד…
• Action Pack - מטפלת בחלוקה בין הבקר לתצוגה בארכיטקטורת MVC.
• Helpers - עזרים - למעשה הם חלק מה-Action Pack. בחלק התצוגה של ארכיטקטורת MVC ניתן להשתמש בקודים מקוצרים רבים שיוצרים קוד html. טפסים ו-ajax זה רק חלק מהדברים שהעזרים הופכים לקלים הרבה יותר.

קצת על ActiveRecord

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

לסיכום

Ruby on Rails היא מערכת ששווה מאוד לבדוק אותה באם אתם מחפשים שפת צד שרת ללמוד. אם תרצו ללמוד על המערכת לעומק, אני מציע שתחפשו ספרים בנושא - אני לא אמרתי לכם את זה, אבל פשוט חפשו ruby on rails באימיול… כמובן שניתן גם לגשת לכאן ולבחור ספר…

אה, עוד משהו…

אהבתם את הבלוג? הרשמו אליו. קורא RSS או כתובת דוא"ל זה כל מה שאתם צריכים.

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

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

1. דרוש כסף רב על מנת לממן עסק חדש - לא נכון. לסטארט-אפ האופייני דרושים רק 25,000$ ע"מ להתחיל להתגלגל. יזמים מוצלחים שלא מאמינים במיתוס הזה בונים את העסק שלהם בצורה שבה הוא לא יצטרך הרבה מזומנים ע"מ לפעול. הם שואלים במקום לשלם, הם שוכרים במקום לקנות, והם הופכים עלויות קבועות לעלויות משתנות, למשל ע"י תשלום עמלות במקום משכורת.
2. קרנות הון סיכון הן מקום טוב לכסף בשביל חברות סטארט-אפ - לא נכון, אלא אם כן אתם בתחום המחשבים או הביו-טכנולוגיה. מחשבים, חומרה, תוכנה, תקשורת וביו-טכנולוגיה הם תחומים בהם 81 אחוזים מכספי קרנות הון הסיכון מושקעים בהם, ו-71 אחוזים מהחברות שקיבלו כספים מקרנות כאלו הן בתחומים הנ"ל. קרנות הון סיכון מממנות כ-3000 חברות בשנה, מתוכן רבע נמצאות בשלבי ההקמה או הסטארט-אפ. למעשה הסיכויים של חברת סטארט-אפ לקבל כסף מקרן הון סיכון הוא אחד ל-4000. זה סיכוי יותר נמוך מליפול ולמות במקלחת…
3. רוב ה"אנג'לס" (מלאכים) הם עשירים - לא אם ההגדרה שלכם לעשיר היא ההגדרה הרגילה של בעל שווי נקי של יותר ממליון דולר או בעל הכנסה של 200,000$ בשנה כרווק או 300,000$ כנשוי. כמעט שלושת רבעי מהמשקיעים שהם לא חברים, משפחה או שכנים לא מגיעים לרמות ההכנסה שמגדירות "עשיר". למעשה, כ-32% מהם הם בעלי הכנסה של פחות מ-40,000$ לשנה, ול-17% ישנם יותר חובות מנכסים.
4. סטארט אפים לא יכולים להיות ממומנים ע"י חובות - למעשה, מימון ע"י חוב הוא יותר שכיח ממימון ע"י הון עצמי. לפי סקר של הבנק הפדרלי בארה"ב על מימון לעסקים קטנים כ-53% מהמימון לחברות בנות שנתיים ופחות מגיע מחוב, רק 47% מהמימון מגיע מהון עצמי. כך שיזמים רבים לווים במקום להשתמש בהונם העצמי.
5. בנקים לא מלווים כסף לסטארט אפים - שוב, הבנק הפדרלי מצא שכ-16% מהמימון לחברות בנות שנתיים ופחות מגיע מהלוואות מהבנקים. 16% לא נראה מספר גבוה אבל הוא גבוה ב-3% ממקור המימון הבא ברשימה - אשראי מספקים. אח"כ מגיעים המקורות האחרים שכולם מדברים עליהם - המשפחה, חברים, אנג'לים, הון סיכון, משקיעים אסטרטגיים ומקורות ממשלתיים.
6. רוב היזמים מתחילים עסקים בתחומים מצליחים - העובדה המצערת היא שההיפך הוא הנכון. רוב היזמים ניגשים היישר אל התחומים הגרועים ביותר לעסקים חדשים. המתאם בין כמות היזמים שנכנסים לתחומים שונים לבין כמות החברות שנכשלות בתחומים השונים הוא 0.77. המשמעות של זה היא שרוב היזמים בוחרים תחומים שבהם רוב סיכוייהם להיכשל.
7. הגידול של העסק תלוי יותר בכישרונו של היזם מאשר בתחום בו הוא בחר לפעול - מצטער אם אני מוציא את האוויר מהאגו של רבים, אבל לתחום בו היזם בוחר ישנה השפעה גדולה על סיכויי הגידול של העסק. בעשרים השנים האחרונות יותר מ-4.2% מהחברות החדשות בתחומי המחשבים והציוד המשרדי הגיעו לרשימה של inc 500 של החברות בעלות קצב הגידול המהיר ביותר בארה"ב. בהשוואה לזה, 0.005% מהחברות החדשות בתחום המלונאות הגיעו לרשימה הנ"ל, כך גם-0.005% מהחברות החדשות בתחום האוכל והמשקאות. המשמעות של זה היא שיש לכם סיכוי גדול ב-840 להגיע לרשימת inc 500 אם אתם בתחום המחשבים ולא בתחום המלונאות.
   בניגוד לזה, אין כל ממצאים מדעיים על הקשר בין כשרונו של היזם לסיכויי עסקו לגדול.
8. רוב היזמים מצליחים כלכלית - מצטער. אמנם יזמים יוצרים עושר גדול, אבל הוא לא מתחלק בצורה שווה. ההכנסה השכיחה של בעלים\מנהל של עסק קטן היא 39,000$ בשנה. רק 10 האחוזים העליונים בין היזמים מרוויחים יותר מהעובדים שלהם, ורוב היזמים מרוויחים בעסקם פחות מאשר היו מרוויחים אילו היו עובדים כשכירים באותו התחום.
9. רוב חברות הסטארט אפ מצליחות להגיע לתוכניות הגידול שהמשקיעים שלהם מצפים להם - אפילו לא קרוב. מכ-590,000 העסקים החדשים שמוקמים בארה"ב בכל שנה פחות מ-200 מגיעות אחרי שש שנים למכירות בסך 100 מליון דולרים שעליהם מדברים משקיעים בהון סיכון. בערך 500 חברות מגיעות למכירות של 50 מליון דולר עליהן מדברים מלאכים רבים. למעשה, רק כ-9,500 מגיעות למכירות של 5 מליון דולר בשנה בזמן של 6 שנים.
10. להתחיל עסק חדש זה קל - זה לא, ורוב האנשים שמתחילים עסק נכשלים עוד בתהליך ההקמה שלו. אחרי שבע שנים רק שליש מאלה שהמשיכו יהיו הבעלים הגאים של חברה בעלת תזרים מזומנים חיובי שעולה על ההוצאות והשכר של הבעלים במשך שלושה חודשים רצופים…

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

הגדרה אנציקלופדית לאניני טעם:

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

ובעברית של אנשים רגילים:

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

לפני RSS

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

אחרי RSS

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

איך משתמשים ב-RSS?

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

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

בשביל לרכז תכנים לקורא RSS אנחנו צריכים קודם כל לבחור קורא RSS.

ישנם קוראי RSS שמגיעים ביחד עם דפדפנים (למשל Firefox או אינטרנט אקספלורר 7)

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

Google Reader (המועדף עלי)
RSSReader
Feedreader

וכו'.

בחרתי קורא RSS. מה עכשיו?

תציצו כלפי מעלה - בצד ימין של סרגל הכתובת שלכם (אם מערכת ההפעלה בעברית אז בצד שמאל שלו) - יש שם צלמית כזו:

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

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

נהניתם? אתם רוצים עוד? הרשמו (כן, גם ב-RSS)

Mode/View/Controller

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

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

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

איך נחלק את העבודה? אם יש שלושה אנשים בוועדה, למשל, אולי כל אחד יכתוב מילה שלישית?

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

לא. זה לא יעבוד טוב.

צריך חלוקת עבודה יותר מובנית.

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

אז מה הדרך הטובה ביותר לחלק את העבודה בתכנון תוכניות מסובכות?

בשנות ה-70 החבר'ה בצוות ה"סמול טוק" בחברת Xerox פיתחו מודל עבודה מעניין - Model/View/Controller (MVC) - הרעיון היה להפריד את המידע בה משתמשת התוכנית, לבין התצוגה של המידע ובין המניפולציה של המידע.

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

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

ועכשיו הת'כלס - מה זה MVC?

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

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

ייתרונות השיטה מבחינת נוחות התכנות

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

אגב, שימוש שרבים עושים ב-MVC אבל לא קוראים לו כך הוא ההפרדה בין העיצוב לתוכן בדפי אינטרנט. (כן כן, XHTML ו-CSS)

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

נהניתם? הרשמו לבלוג וקבלו עדכונים כשיש משהו חדש.