פיני דיין כותב בבלוג שלו על שני classים נידחים שמתחבאים להם ב-System.Web כדי לשמור צמדים ושלשות של אובייקטים: Pair ו-Triplet. אני חושב ששימוש באובייקטים הללו הוא רעיון רע, ועדיף שיקברו יחד עם ה-.NET Framework 1.0 שהוליד אותם. יש לי שתי סיבות:
א) המחלקות הללו יושבות ב-System.Web.UI, שיושב תחת System.Web.dll. אם אני לא כותב מערכת Web, זה מיותר לחלוטין להוסיף Reference ל-System.Web רק בשבילהם. וזה גם בלי להזכיר שהם לא היו אמורים לשבת ב-Namespace הזה מלכתחילה – אין בהם שום קשר ל-UI. גם אין בקלאסים הללו שום תחכום או לוגיקה שאנחנו לא יכולים לכתוב בעצמנו ב-3 שורות קוד שלא גוררות Reference.
ב) השנה היא 2009, והגרסא היא .NET 3.5, וכבר 4 שנים אין הצדקה לעבוד עם רכיבים מסוג Object ועלויות ה-boxing וה-casting שהם גוררים. אין שום בעיה להגדיר אובייקט Pair<FirstType, SecondType> ולהשתמש ב-Generics בשביל זה. אני אצטרך טיעונים ממש טובים כדי לשקול עיצוב שדורש צמדים לא מוגדרים של אובייקטים לא ידועים.
שפות התכנות שאיתן אנחנו עובדים קשורים באופן הדוק לשפה האנגלית שעליה הן בנויות – לולאות While ותנאי If הם הבסיס של שפות רבות, ורוב המידע שאנחנו מתבססים עליו הוא באנגלית, ממאמרי MSDN לספרים ולהרצאות מוקלטות באינטרנט. לכן זה לא מפתיע שבמקומות רבים – רוב מקומות העבודה שעבדתי בהם – כל ההתעסקות סביב התכנות היתה באנגלית, כולל מסמכי העיצוב והתכנון ואפילו האימיילים הפנימיים בין המתכנתים בענייני הפרוייקט.
הנוהג הזה כל-כך נפוץ שאני מכיר מתכנתים רבים שמתנגדים באופן נחרץ לשילוב של עברית במסמכים הטכניים של המערכת. המטרה שלי כאן היא להעלות כמה סיבות חשובות בעד כתיבת מסמכים בעברית. אפילו מסמכי עיצוב וארכיטקטורה.
נתחיל מזה שאני אדגיש שאני לא מרחיב את ההמלצה הזו לכתיבת קוד בעברית. למרות ש-C# ושפות מודרניות אחרות מאפשרות הגדרת משתנים עם שמות ברוב טווח ה-Unicode, אני חושב שלשלב תווים עבריים בתוך הקוד עצמו זה רע1. גם כי השפות עצמן נכתבות משמאל לימין וגם כי זה גורם לשינוי-הקשר2 חריף לקורא. גם בהערות אני נגד כתיבה בעברית, בעיקר בגלל עניין השמאל-לימין ברמת הפסקה.
בעניין המסמכים, לעומת זאת, אנחנו צריכים לזכור שהמטרה של מסמכי העיצוב הם להיות ברורים וקריאים ככל האפשר. גם ככה יכולת התבטאות בכתב היא לא ברשימת הדרישות מתפקיד של תכניתן או ארכיטקט, ובפעמים רבות לקרוא מסמך עיצוב הוא תהליך ארוך ומפרך של פענוח כוונה שנסתרת תחת גבב מילים. התוכן המקצועי הוא פעמים רבות מסובך מספיק, והייתי רוצה להציב לכותבים ולקוראים כמה שפחות מכשולים בדרך להבנה. ומה לעשות שבארצנו דוברת העברית, הרוב המוחלט של האנשים כותבים וקוראים עברית שוטפת הרבה יותר מאשר אנגלית. רוב הישראלים, גם אלה שדוברים אנגלית שוטפת, מתבטאים טוב יותר וקוראים מהר יותר בעברית. כמו שיש הצדקה לבלוגים טכניים בעברית וספרי לימוד בעברית, כך יש גם הצדקה לכתיבת מסמכי פרוייקט בעברית. יקח פחות זמן לכתוב אותם. יהיו פחות אי הבנות בקריאה שלהם.
יש שלוש התנגדויות ראשיות שנתקלתי בהן לכתיבת המסמכים בעברית:
1. השפה הטכנית שבה כתובים המסמכים שזורה בביטויים לועזיים, ואין דרך אחת נכונה להתמודד עם זה. חלק מהמונחים אפשר לתרגם אבל רובן נשמעות מאולצות ולא טבעיות. אפשר גם לא לתרגם ולהשאר עם המונחים באנגלית, אבל אז יש את הבעייתיות של שילוב טקסט אנגלי בתוך עברי. איך אני כותב “design pattern” בעברית? והאם אני מציין שאני מממש את ה-Design Pattern של המפעל הסטטי, או של ה-Static Factory? ומה עם מונחים שהם באנגלית, כי הם מציינים שמות שבאים מהקוד עצמו? אני אדבר על “מחלקת Customer”?
יש כאן בעייתיות, אני מסכים, אבל אני חושב שאפשר יהיה להתרגל די בקלות. תרגומים פופולריים (מחרוזת, מסד נתונים) יתורגמו. מונחים אחרים ישארו באנגלית בגוף הטקסט. לא תמיד אפשר למצוא פתרונות מושלמים לשילוב עברית ואנגלית, אבל אנחנו רגילים לזה.
2. תכניתנים צריכים לדעת אנגלית. תיעוד ב-MSDN הוא באנגלית, רוב החומרים והבלוגים בעולם הם באנגלית, ושליטה באנגלית היא רף-כניסה ראוי לתחום. עם הטענה הזו אני כבר לא מסכים לחלוטין. יש הרבה אנשים עם כל הכישורים להיות מתכנתים מצוינים, אבל שהאנגלית שלהם חלשה. זו הסיבה שהוקם האתר הזה, והסיבה שיש User Groups בארץ. אני חושב שיש לתחום כולו רק להרוויח מהורדת רף הכניסה.
ומעבר לכך, העובדה שאדם שולט באנגלית ומסוגל לקרוא ולכתוב בלי בעיה לא אומר שהוא יקרא ויכתוב ביתר קלות בעברית. אנחנו לא מחפשים להערים מכשולים מלאכותיים.
3. חברות בימינו נוטות להיות רב-לאומיות. פרוייקט יכול להתחיל בארץ ולעבור לקבוצת פיתוח בחו”ל. סטרטאפ יכול לתלות את המודל הכלכלי שלו על כך שיקנה ע”י גוגל. כל אלה טיעונים לא רעים בכלל, אפילו משכנעים. זה שיקול פרקטי של השענות על האנגלית כעל ה-lingua franca של העולם, ובטח של העולם הטכנולוגי. אם זה המצב, שווה להשאר באנגלית. אבל אני חושב שזה לא ממש מתאר את רוב המצבים.
1. האמת היא שיצא לי לכתוב משתנים בעברית פעם אחת – ב-SharePoint WebParts, הממשק מייצר Drop Down על פי הערכים של enum, והדרישה היתה שהערכים יהיו בעברית. היה לי קשה עם זה.
2. יש למישהו מונח עברי טוב ל-Context Switch?
Tomorrow I am bidding my laptop farewell, and will soon buy me a new one. This results in what I like to call Settings Anxiety. I spend months tuning various aspects of my computer to my liking, and starting afresh with a new machine is wearisome. There are solutions to this, of course. I can make a full settings backup using Windows Easy Transfer or some such tool to store my settings and registry information and reload them on my new computer. I am, however, leery of it. First of all, I don’t trust WET to backup everything, especially 3rd party settings and application data. Secondly, I don’t want to copy all the cruft that’s accumulated in my user settings. One advantage to leaving the old computer is to start fresh.
So my compromise is to do a set of manual exports for various pieces of software, to carry it with me to the new computer, whenever it arrives. I’m going to list the various programs I use here that I bothered to customize, and detail the steps needed to do a manual export. This way I can come back to it the next time I reformat.
1. Outlook 2007
I use Outlook to connect to an Exchange server and to Gmail via IMAP. Both of these use OST files for local offline caching, but the primary storage is on the server. No real need for me to back this up.
Unfortunately, there’s no way to export my Outlook profile’s entire Accounts list to a file, and reimport it later. It means I always have to go to Gmail’s help page to remember the port numbers they use for encrypted IMAP and SMTP, but it’s not too much of a hassle.
2. Visual Studio 2008
Two important customizations here – color scheme (I like grey background) and keyboard shortcuts (single-click build-current-project ftw!). Both are easily exported using Tools –> Import and Export Settings –> Export selected environment settings.
3. Google Chrome
Bookmarks, cookies and stored passwords – things I really don’t feel like retyping again and again after I got my Chrome to memorize it for me. Basically, with all major browsers importing favorites and settings from one another, you only really need to backup one browser’s settings.
Unfortunately, Google haven’t quite gotten around to implementing Export Settings in Chrome – like a lot of other things. To backup my settings, I am copying the C:\Users\username\AppData\Local\Google\Chrome\User Data folder. There’s a lot of useless junk there – the cache, Google Gears data – but it should contain all the interesting bits too.
4. RSSBandit
RSSBandit’s “Export Feeds” option will probably export the feed definitions, but not the actual text of the actual feeds that I already have, offline, in my reader. It does support exporting the list of items in a feed, including read/unread state, though. But a better solution, assuming I am unbothered by space or time, is to use RSS Bandit’s “Remote Storage” option to save the entire feed database to a ZIP file that can be “downloaded” into a new installation. Under Tools –> Options –> Remote Storage set the destination (I use a file share), then do Tools –> Upload Feeds.
When recovering, I’ve found that RSS Bandit doesn’t always succeed in reading the ZIP file – I got a “file was closed” error. What I did was simply open the ZIP file and copy all the XML files into the %AppData%\RssBandit folder, et voila.
5. Windows Live Writer
Another useful tool that wasn’t given an Export Settings option. There are two things to backup here:
1. My blog settings – I have 5 different blogs I manage through WLW. Here I had to go back to the Registry. Funny how it seems so old-fashioned. Export all settings from HKEY_CURRENT_USER\Software\Microsoft\Windows Live\Writer.
2. Blog drafts and recently-written posts are stored in My Documents\My Weblog Posts. Would be a good idea to back those up as well.
3. When restoring settings, it initially appears that while the blog settings are properly recovered, the drafts aren’t. All you need to do, though, is double-click on one of the .wpost files in the My Weblog Posts folder, and the Drafts and Recently Posted lists will get populated.
6. Digsby
Digsby, the multi-protocol IM and Social Networking tool, uses a centralized login to store the settings of my different protocols – so I only need to log in with my Digsby ID to have all my IM networks working. There are some tweaks to the client itself which I would like to not lose, but they don’t provide an Export Settings feature either, and it’s nothing I can’t live without.
For most other things, I’d rather not bother until I actually need it.