קטגוריה: ui

ממשקי משתמש – יצירתיות מול שימושיות

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

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

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

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

נלקחת מ: https://commons.wikimedia.org/wiki/File:Mission_Accomplished_-ALS_Ice_Bucket_Challenge(14848289439).jpg

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

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

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

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

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

אני חושב כי אנשי ux/ui חייבים ללכת ולעשות שיעורי בית מול דבר ראשון אלו שצריכים להשתמש במערכת ולהתחיל להקשיב לאנשים עם בעיות שונות, ורק אז לחשוב איך לעצב את זה בצורה "סקסית" ו"מושכת", אחרת הניתוח הצליח, אבל החולה מת.

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

לשחק עם כובש ההשלמות

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

השלמת תוכן ב nvim

החלטתי בהמלצת מאיר לנסות את coc – שפירושו הוא Conquer of Completion .
התוסף הוא בפני עצמו מאוד מעניין. הוא משתמש מאחורי הקלעים בחלק מכובד של תוספים המגיעים מ Visual Studio Code של מיקרוסופט, בנוסף לשימוש ב LanguageServer.
הוא מחזיק בתמיכה של "חלונות צפים" שנכנס לשימוש ב neovim רק לאחרונה:

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

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

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

עד כאן הכל טוב

אבל, שמתי לב למספר בעיות חדשות שצצו לי במערכת. למשל בגלל שcoc משתמש ב node, הוא שוקל יחסית הרבה בזמן ריצה על ה cpu ולא רק על הזיכרון.

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

שורה תחתונה

אחרי חודש וחצי של משחקים, אני חייב לציין שאני מאוד אוהב את coc, וחושב לייצב אותו יותר ב"הפצה" שלי של vim.

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

 

על שימוש ב VIM ו OCD

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

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

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

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

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

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

אבל הגישה של vi היא שונה כאן. אם כל משפט נגמר בנקודה, אפשר להתחיל בגישה הבאה:
בואו נלחץ על ‏ 2f.‎ (כלומר הספרה שתיים האות f ואז נקודה) ונגלה כי אנחנו מגיעים לנקודה השלישית הנמצאת בשורה שלנו. עכשיו ניתן להקיש 2w ו… הגענו למיקום הנכון. מכאן נלחץ על cw ונשנה את המילה הרצויה.

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

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

תנו לי לנסות את זה שוב. אולי אעשה את זה כך: ‎ 2‎)‎ ואז על w ואקנח ב cw.  טוב זה פחות הקלדות.
ועכשיו נשאלת השאלה – האם אני עדיין יכול לקצר את התהליך. אמנם במקום 7 תווים ירדתי ל5, עדיין זה הרבה בעיני.

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

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

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

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

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

חודש עם Tilix

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

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

הדבר הקרוב ביותר שמצאתי הוא תוכנה בשם Tilix, אשר קיבלתי עליה המלצה. התוכנה עצמה כתובה בשפה בשם D, והיא מספקת המון תכונות מדהימות, אשר חלקן לקוחות מכלים כדוגמת screen ו tmux, וחלקן מ iTerm2.

tilix

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

בנוסף לכך שיש לי split שקל לעבור בניהם עם המקלדת, אפשר גם ליצור משהו שנקרא session, ממש כמו virtual desktop. וגם אליהם ניתן לעבור בקלות עם המקלדת.
היא מאפשרת למשל לשתף מקלדת עם כל או חלק מהטרמינלים הפתוחים בסשן, כך שהקלדה במקום אחד תתקבל גם בשאר, חיפוש של תוכן שהודפס למסך (למשל לוג שאתם פתחתם עם tail -f, ואולי פספסתם משהו בו), ואפילו ניהול של clipboard, בנושא שאל העתקה והדבקה, ולא בניהול של היסוטוריה וכיוב' שלו, הוא יודע לספק הודעת מערכת כאשר פעולה הסתיימה, להגדיר מסוף כ readonly (לא מקבל מקלדת, בניגוד ל CTRL+S שפשוט משהה את הפעילות) ובנוסף, יש לו תמיכה בכלים שונים שלא ניסיתי עדיין.

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

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

אבל זה לא הכל, אני יודע שכאן אני תלוי בטרמינל, ולא בתוכנה שרצה בטרמינל, אבל בסופו של דבר, האם זה משנה אם התוכנה נקראת tmux, screen או אולי Tilix?

ובכן, קצת 🙂

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

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

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

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

 

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

מימוש RDP טבעי בשפת רובי

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

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

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

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

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

כתובת הפרויקט: https://github.com/Safe-T/rdp-rb

שבוע עם Atom

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

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

העורך משתמש בחלקים של כרומיום, ב node.js, ומשתמש גם ב coffeescript עבור התצוגה של דברים (הנעשים בcss).

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

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

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

  • היכולת להגדיר מה הוא API תקין מבחינת תוספות ולא לאפשר תוספות שאינן כאלו
  • היכולת להגדיר תוספים על בסיס מה שאני עובד כרגע
  • קבלת תוספים איכותיים מבית github לשפות שונות, כדוגמת PHP, רובי וכיוב', מעבר למה שמגיע כברירת מחדל.

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

הבעיות שיש לי עם תכנות ריספונסיבי

הקדמה

אנחנו חיים בעולם שיש בו המון מילות באזז, כדוגמת big data, responsive design, cloud computing, סייבר וכיוב' …
כל המילים האלו מגיעות מעולם השיווק, אבל לאדם טכני לא באמת אומרות הרבה.

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

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

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

מונחי יסוד

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

CSS – הם קבוצה של חוקים אשר יכולים לכסות אחד את השני (מכאן השם: Cascading Style Sheet) בצורה שתספק עיצוב למסמך.

הסבר

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

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

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

כך שאולי יש מסמך איכותי עם המון מידע, שמעוצב מדהים ויודע להיות מוצג בהרבה רזולוציות, אבל האם הוא באמת יודע להגיב כמו שצריך למגבלות המכשיר אשר המסמך מוצג בו?

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

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

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

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

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

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

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

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

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

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

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

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

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

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

מערכת פשוטה לשיתוף קבצים פנים ארגונית

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

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

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

אז החלטתי כי במקום להמשיך ולחפש תוכנה, אכתוב משהו פשוט שיעשה את זה, ותוך שעה וחצי, כולל דיבוג כתבתי את simple file sharing – גרסת mercurial וגרסת git.
זהו מנוע פשוט, הכתוב ברובי עם סינטרה ללא javascript שאני כתבתי, אלא cgi מול html/css פשוטים מאוד מבוססי foundation.

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

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

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

Firebird וליברה אופיס

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

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

ביולי 2013, פרסמתי כי Base מקבל תמיכה בFirebird כחלק מפרוייקט SOC.

החל מגרסה 4.2, במידה ומפעילים תמיכה ביכולות נסיוניות, ניתן לקבל תמיכה בFirebird כמסד נתונים embedded עבור Base.
libreoffice base firebird בשביל לקבל תמיכה בדברים ניסיוניים בליברה, פשוט הולכים בתפריט ל Tools משם ל LibreOffice, משם ל Advanced ולוחצים על Enable experimental features.

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

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

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

Firebird פוגש את ליברה אופיס

פרוייקט הפיתוח GSOC מבית גוגל כמובן, הביא לכך שנכון לשבוע שעבר, יש דריבר רשמי לFirebird בתוך LibreOffice Base.

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

על מנת לגרום לו לעבוד בקובץ odb, יש לשנות הגדרות של

EmbeddedDatabases/DefaultEmbeddedDatabase/Value

מהערך של

sdbc:embedded:hsqldb

לערך:

sdbc:embedded:firebird

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

הבלוג המקורי בנושא. קוד המקור בgit.
 

הפצת לינוקס מול תוכנה

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

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

אז מה הן הבעיות ? הנה רשימה חלקית:

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

Windows 8 לפי סמי

זוכרים ששאלתי האם Windows 8 מציג סוף עידן למיקרוסופט ?

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

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

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

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

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

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

מיקרוסופט ו PC – סוף עידן (?)

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

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

ms-surface - windows 8אני חייב לציין כי למעט מספר בעיות קטנות יחסית, כאשר מתעסקים עם Microsoft Surface בחומרה שאליה החברה כיוונה, המערכת מתפקדת מצויין ונוחה מאוד (כאמור למעט בעיות קטנות).

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

שלום גנום שלוש

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

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

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

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

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

אבל דווקא לאנשים שגולשים הרבה, או משתמשים ב IM (שגם כאן ארץ' שברו דברים בייחד עם עוד כמה דברים הקשורים לגנום 3), הגישה הנוכחית לדעתי הרבה יותר נוחה, מאשר הגישה הקלאסית. לפחות עבורי.

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

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

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

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

Display Quote ההמשך

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

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

display_quote_navigation_mode

החלטתי עכשיו לשים לעצמי 2 מטרות לגרסה שאני יוצר:

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

הבעיה עם פייסבוק, היא שאסור לי לפרסם את הסיסמה שהפרוייקט קיבל, ובנוסף אני צריך ליצור או להתחבר למימוש של OAuth2, אשר שונה מ OAuth1 למשל …

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

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

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

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

display_quote_edit_mode

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

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

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

עוד רעיונות ממכם יתקבלו בברכה.

הקוד עצמו, ד"א כרגיל נמצא ב github.

Gtk3, GObject Introspection ו Free Pascal

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

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

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

קובץ כזה יראה כך: להמשיך לקרוא

Zoho Mail vs Google Mail

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

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

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

ממשק גרפי לציטוטים חלק שלישי

Quote Window

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

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

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

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

הנה מספר קטן של ניסויים שעשיתי בממשק: להמשיך לקרוא

זה ציפור, זה מטוס, זה kde 4 לא זה Windows 7

יצא לי אתמול פעם ראשונה לראות ולעבוד על Windows 7 במציאות.  טעם הWindows שעבדתי עליו היה Home Premium בעברית, ואני חייב לציין שידידות זו לא התוכנה הבולטת שלו.

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

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

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

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

ב W7 יש גם אפשרות למצוא ערכות נושא שממש מזכירות את Gnome, ובכלל כל המערכת והסביבה מזכירה כאילו לקחו את KDE 4 ואפילו כמה פיטצ'רים שהיו קיימים ב KDE3 והוסיפו אותם לסביבה הגרפית וקראו לזה Microsoft Windows 7. אולי היו צריכים לקרוא לזה "טעם KDE 4" ולסיים עניין 🙂

בשורה התחתונה, נראה כי מיקרוסופט עשו copy paste לסביבות לינוקס ואח"כ עוד אומרים שלינוקס לא ידידותית…

קישור ל Qt

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

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

סוני ואיו ולינוקס

Sony VAIO vgn-nr498e

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

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

Where have all the user friendlines go ?

I've been going over some RSS feeds, and I found the following link.

This link is about a technical book from the 80's. I remember something from the 80's regarding books: they where more then just pages, but interactive, and many time more friendly then any good  book or tutorial that we have today.

It makes me wonder, where did we loose the simplicity approach and returend to the more "clean" one, that books must be plain text, not interactive etc…

הקרב של מריוס

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

לאחרונה החליט מריוס לקרוא תיגר על 2 דברים:

  1. עבודה עם Internet Explorer
  2. עבודה עם Windows בכלל

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

מעבר ל KDE 4.2

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

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

האם זה Windows 7 או בכלל KDE 4 ?

שני אנשים מ ZDNet אוסטרליה עשו ניסוי רחוב, והציגו את KDE 4 ואמרו שהוא Windows 7. תראו את התגובה של האנשים ברחוב:

http://www.zdnet.com.au/insight/software/soa/Is-it-Windows-7-or-KDE-4-/0,139023769,339294810,00.htm

פרשנות שלי לדרישת האיחוד האירופי בקשר להסרת Internet Explorer

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

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

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

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

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

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

להריץ webkit עם FPC/Lazarus

התפרסה תמונה של תוכנית שכתובה ב QT4 המריצה את WebKit. עד כאן אין שום דבר לכאורה יוצא מן הכלל.

ובכן התוכנית שמריצה את WebKit כתובה כולה ב FPC והממשק משתמש בלזרוס.

הספריות QT שהתוכנית משתמשת בהם הינם:

# ldd fpc_webkit_demo | grep libQt
. libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb79b8000)
. libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb7090000)
. libQtNetwork.so.4 => /usr/lib/libQtNetwork.so.4 (0xb6f8e000)
. libQtWebKit.so.4 => /usr/lib/libQtWebKit.so.4 (0xb669c000)

מדהים אותי כל פעם מחדש לראות את הקדמות התמיכה בQT בכל מה שקשור ל FPC ולזרוס, ועכשיו כש QT 4.5 הולך לצאת בתור LGPL, אז לדעתי אפשר לראות רק יותר שימושים נורמליים עבור QT, במקום עוד ספרייה שמנסה לגרום ל ++C להיות שימושי…

לעבוד עם מערכת הפעלה לא מוכרת*

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

רכשתי ב460 ש"ח את ההפצה של החברה. ההפצה הספציפית היא Vista Home Basic למעבדי 64 ביט והיא אמורה להיות תומכת עברית. מוזר בהפצות הלינוקס מעולם לא הייתי צריך הפצה מיוחדת לעברית… נו טוב, כנראה שכאן זה אמור להיות ממוקד יותר מבחינת כיווניות וכו', ואפשר לצפות שהדו כיווניות כנראה יעבוד הרבה יותר טוב. אבל עדיין, את מנדריבה Power Pack אפשר לקנות ב100 ש"ח, והיא מכילה הרבה יותר ממה שכתוב ש Vista Home Basic. ורוב הפצות הלינוקס ניתן להוריד בחינם, כך שהעלות היא של חיבור האינטרנט והמדיה שאיתה אנחנו משתמשים. כנראה שאני מקבל הרבה מאוד דברים על ההתחלה ב Home Basic שאני לא מקבל בלינוקס. להמשיך לקרוא

הגישה של KDE

אם אתם עדיין לא יודעים, אז KDE שיחררו את עץ 4 של שולחן העבודה ליוניקס.

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

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

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

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

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

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

KDE 4.0.1

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

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

אחרי הגיבוי בחרתי את KDE4 מתפריט KDM, ונכנסתי אליו.

אני חייב לציין שהממשק פשוט מדהים, אין מילה אחרת לתאר את זה. הוא רחוק מלהיות מושלם, וחסרים לו הרבה מאוד דברים שאני מוצא אותם שימושיים ב KDE3, אבל סה"כ מבחינת מראה + שימושית (בייחד), KDE עשו עבודה מצויינת, שמקבלת ממני 85% מתוך 100%.

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

System Control, קרס לי גם בחלק ממסכי ההגדרות, אבל תוכנות מבית KDE 3 רצו יפה, אם כי Kopete למשל לא היבהב לי כאשר מני ענה לי על הדיווח שאני מדבר איתו מאחורי KDE4 .

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

לגבי התוספים, לקחתי למשל מציג תמונות, שמתי לו את ספריית התמונות שלי בתור slide show והוא התחיל להציג 146 תמונות בצורה רנדומלית. ולמרות שהתעללתי בתוסף, סובבתי אותו, הגדלתי והקטנתי, זה פשוט עבד ! יפה 🙂

אחרי שסיימתי לשחק עם KDE4, חזרתי ל KDE3 וחשכו עיני ! להמשיך לקרוא

האם Windows מתאימה לשולחן העבודה

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

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

להמשיך לקרוא

כלי האלטרנטיבה בלינוקס

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

הדבר הזה שונתן לי לנהל את השימוש בתוכנה והגרסה שמתאימה לי נקרא alternatives.

ניתן למצוא אותו ברוב ההפצות תחת /etc/alternatives/ שם תראו הרבה קישורים סימבוליים לתוכנות, לספריות ולקבצי עזרה של man.

להמשיך לקרוא

לראות שונה – תכנות

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

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

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

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

למען הפרוטקול, אני יודע לתכנת בהרבה שפות תכנות: משפות "נמוכות" כדוגמת assembly 16 ביט של x86, וכן גם הגרסה שמוגנת של 32ביט (או לפחות זוכר איך לעשות כמה דברים עם השפות האלו). אני גם יודע לגעת בC אם כי בצורה די בינונית, Java, Perl, Ruby, Bash כמובן שפסקל, ועוד… אני כמובן גם יודע שפות יעודיות כדוגמת nasl מבית nesus או SQL בהתאם למסד הנתונים והרשימה עוד ממשיכה.

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

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

כאשר אני רוצה לבנות קוד שיעבוד במהירות על טקסט, אני אעדיף את פרל. חוצמזה שאני מאוד אוהב את השפה, היא פשוט בנוייה לזה. אין כיום שום שפה אחרת שתיתן לי את מה שפרל נותנת (אל תזכירו את awk בבקשה).
אם אני רוצה לבנות אתר Web, אני אבחר או בRuby או בPerl. שוב, הם הכלים הכי טובים לדעתי לביצוע המשימה. לדוגמה PHP רק בגרסה 5 התחיל להתקרב למצב שניתן להשתמש בו בצורה טובה, אבל הוא עדיין רחוק מהמטרה. נראה כי Zend מסתובבים סביב המטרה, אבל לא מגיעים אליה… כרגע הם רק הקטינו את גודל המעגל.

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

לGUI, אני בוחר בLazarus, אשר הרבה יותר טובה מכל הכלים הקיימים כיום בשוק ללינוקס.

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

אז מה אתם אומרים ? האם אתם תבחרו כלי ושפה שתבצע לכם את המשימה הכי טוב שאפשר, או שתבחרו בכלי הכי פפולרי, גם אם הוא לא בהכרח יעשה את העבודה כמו שצריך בלי מאמץ כזה או אחר מצדכם ?

פיתוח מהיר וקל

לפני יומיים התקנתי (גם אני) את FPC 2.2.0. וכרגיל בניתי אחרי עדכון עוד גרסה של Lazarus ישירות מה svn. גרסת ה QT4 שאני לאחרונה ערכתי עליה ניסויים עדיין רחוקה מלספק לי כלי נורמלי לפיתוח (ואני באמת מצר על כך).
אז החלטתי לנסות אחרי התעלמות רבת החודשים, שוב את GTK 2 בלזרוס. חשוב לי להזכיר כי יום לפני שחרור FPC 2.2.0 ניסיתי את גרסת GKT2 של לזרוס שקרסה בזמן עליית הIDE.
אבל פתאום על אותה גרסת SVN לתדהמתי Lazarus פשוט עובדת. ועובדת די טוב יחסית לגרסה לא יציבה ולא מושלמת (וכן היא עדיין מכילה הרבה באגים).
עכשיו הצלחתי להשלים את משימת פיתוח ה FastAGI שלי (שנכון לזמן כתיבת הבלוג, נשאר לי רק להתחיל לשלוח פקודות ולקבל את התשובה חזרה). פשוט מדהים.
Lazarus, GTK2, Hebrew

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

פיתוח חוצה פלטפורמות באמצעות Free Pascal 2.2.0

תרגום מהגרסה האנגלית לכתבה שפורסמה בOSNews ע"י Joost van der Sluis
תורגם ע"י עידו קנר

לאחרונה Free Pascal (FPC) שחררה את הגרסה 2.2.0. מהדר הקוד הפתוח לשפת פסקל אשר ממשיך מאז התחיל ב-1993 לגדול ולהיות אחד ממהדרי הקוד הפתוח הכי מתוחכמים הקיימים כיום. מדי יום מפתחים רבים מגלים את FPC ומפתחים את התכנות שלהם באמצעות פסקל מונחה עצמים. הפיתוח של Lazarus תרם לכך באופן מיוחד: Lazarus היא סביבת עבודה משולבת גרפית עבור FPC, עם כלי פיתוח רבים לפיתוח ותכנון תכנות גרפיות.
להמשיך לקרוא

הדגמה לניצול בעיית אבטחה של טלפון תוכנה

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

האתר Blue Box שם לו לדגש להציג בעיות אבטחת מידע בעולם הVoIP באמצעות שידורי PodCast.

אחד משידורי הPodCast מציג הדגמה של בעיית אבטחה בטלפון תוכנה הרץ בWindows. הפירצה מאפשרת ניצול של באג, ונותנת גישה ישירה לShell ב Windows.

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

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

היכולת לבחור -> תוכנות למניפולציות תמונה

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

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

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

[gv data="lyLPZDVdQiQ"][/gv]

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

אז מי אמר שאין תוכנות בלינוקס מגניב