ארכיון חודשי: מרץ 2012

vim omnicomplete

לאחרונה אני מוצא את עצמי חוזר לתכנת בעיקר עם vim במקום kate, היות והאחרון, אוהב לקרוס לי, והרבה.

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

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

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

The Ruby Refresher

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

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

Ramaze

Ramaze הוא Framework מאוד מעניין לעולם הweb הכתוב בשפת רובי. על פניו הוא נראה כמו framework בסגנון MVC רגיל, אשר מגיע בצורה מסויימת וצריך להתמודד איתה כמו שהוא הגיע. בנוסף, מראית העין מצגיה גם כי הוא מאוד מינימאלי, ושאלו אותי למה להשתמש בו ולא בסינטרה. אז צריך להבין כי מדובר רק במראית עין.

בגדול מאוד, הגישה של Ramaze מחולקת ל2:

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

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

Ramaze עצמו בנוי מעל framework נוסף בשם Innate אשר יכול לעמוד גם בפני עצמו ופותח עבור Ramaze. הוא בעצם מספק את שכבת התאימות מול Rack.

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

אז איך מתחילים ?

$ gem install ramaze
$ ramaze create blog
$ cd blog
$ ramaze start

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

My roadmap for open source projects

All work and no play, makes IK a bad open source dev.

Recently I was required to stop the work on my Redis client due to lack of time. But I still going to finish the client, but it will take more time then what I thought it would.

But it made me think, what exactly are the things I wish to develop and contribute for open source projects.

So after the Redis client work, I wish to work on the following projects (some will be mine):

  • Contributing to Adhearsion
  • Creating web framework to fpWeb (It's just a CGI framework, not a whole web framework)
  • Working on a library I wanted to start in 2010 for VoIP
  • Continue working on Redis client when needed

I have no time frame limit for this, but that's the open source stuff I wish to work on when I'll have more time.

fpIndexer

fpIndexer הוא מנוע קוד פתוח הנועד לסרוק טקסט וליצור עבורו אינדקסים אשר יעזרו לחפש טוב יותר את המילים השונות, ואף ליצור מעל התוצר שלו במסדי נתונים, גם מנוע מסוג Full Text Search

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

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

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

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

בזמן כתיבת הפוסט, ישנה תמיכה בארבעה צורות של "שמירה ושליפה של המידע":

  • מסד נתונים בזיכרון
  • קובץ שטוח
  • Firebird SQL
  • SQLight

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

  • קבצי טקסט רגילים (plaintext)
  • קבצי HTML
  • קבצי Pas

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

מעל מאנדקס הטקסט/stream, קיים גם מימוש של אינדקס השייך למסד הנתונים, דבר המאפשר ליצור מנוע full text search מעל מסד הנתונים.

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

האם Framework צריך להתערב בגישות אבטחה ?

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

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

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

Rails מאוד שונה בגישה שלו מהרבה frameworks, בכך שהיא מגיעה בפילוסופיה האומרת כי הוא מכריח אותך לעבוד בגישה שלו:

Rails is opinionated software. It makes the assumption that there is a “best” way to do things, and it’s designed to encourage that way – and in some cases to discourage alternatives. If you learn “The Rails Way” you’ll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.

כלומר  עלייך לעבוד בגישה שלו, או בכלל לא לעבוד איתו, אחרת לא תסתדר במיוחד.

כך שאנו זקוקים לשאול את השאלה: כיצד Rails צריך להתנהג בנושא ?

האם עליו להכתיב את הדרך להגן על שדות ?

או האם מתכנתים צריכים לדאוג לנושא בכל פעם מחדש (למשל Rails מוסיף לכל טבלה 2 שדות בעצמו, אבל לא מגן עליהם, למרות שברירת מחדל הוא מנהל אותן) ?

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

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

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

מה אתם חושבים ?

תשובה לחידה בנושא כתובות IP

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

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

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

התקן אשר מגדיר מה הם סוגי הטווחים השונים, נקרא RFC 3330.

חידה בנושא כתובות IP

יש תקן אשר נקרא RFC 1918.

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

10.0.0.0 10.255.255.255 (10/8 prefix)
172.16.0.0 172.31.255.255 (172.16/12 prefix)
192.168.0.0 192.168.255.255 (192.168/16 prefix)

ועכשיו לשאלה: למה 127.0.0.0/8 לא נמצא שם ?

(צפריר בבקשה לא לענות).

הסבר בפוסט הבא.

הצד האפל של מתודולוגיות פיתוח

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

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

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

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

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

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

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

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

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

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

אני לא מרגיש פראייר

חץ כתב בבלוג שלו על כך שהוא מרגיש קצת פראייר על כך שהוא משלם 400 ש"ח בחודש על שירות שהוא לא משתמש בו באמת.

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