תחומים - פורום חרדי מקצועי

שלום לכולם, יש לי צורך לעשות for each אבל ברוורס, ועוד מדובר ב VBA

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

תודה.

פורסם במקור בפורום CODE613 ב25/07/2013 13:21 (+03:00)

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

בהצלחה.

פורסם במקור בפורום CODE613 ב25/07/2013 13:15 (+03:00)

שלום chaim1989 רציתי רק להגיד לך שאני עדיין לא מבין בדברים האלו לצערי, אז אל תבנה עלי שאענה לך בפורום........ בכל מקרה ד"ש :lol:

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

פורסם במקור בפורום CODE613 ב25/07/2013 13:17 (+03:00)

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\File MRU
מה שנראה שכל תוכנה מחזיקה ערכים ברג'יסטרי
מקור

פורסם במקור בפורום CODE613 ב20/07/2013 22:34 (+03:00)

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

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

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

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

פורסם במקור בפורום CODE613 ב25/07/2013 19:03 (+03:00)

<<לחץ כאן למעבר לשיעור 1
שלום לכולם!

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

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

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

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

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

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

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

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

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

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

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

פורסם במקור בפורום CODE613 ב18/07/2013 01:32 (+03:00)

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

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

בהצלחה.

פורסם במקור בפורום CODE613 ב17/07/2013 23:53 (+03:00)

אבל אני מתרשם שאם אני בונה תוכנה שלא אמורה לתת חויה חזותית מרשימה במיוחד אין צורך ב WPF

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

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

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

בהצלחה!

פורסם במקור בפורום CODE613 ב18/07/2013 11:51 (+03:00)

אוקי, אז אם ככה אני ממליץ לך לעזוב מיידית את WFA אין לך שום ברירה אלא להתקדם, התפיסה של WPF היא שונה לגמרי באופן טוטאלי בכל נושא ה UI קוראים לזה MVVM דהיינו מודל-וויו וויו-מודל
המשמעות היא, שהיוזר כותב וקורא ישירות ל Property וזה דו סטרי. כך שהוויו - מחובר למודל והמודל מחובר לוויו.

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

אתן לך דוגמא פשוטה ותבין את ההבדל בין WPF לבין winform
צור פרוייקט חדש של wpf וקרא לו "SliderBindControl"
אחר כך הכנס את הקוד הבא למטה איפה שייפתח לך חלון חדש, פשוט תחליף את הקוד הקיים בזה שלהלן:

<Window x:Class="SliderBindControl.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        
        <Slider x:Name="slider" HorizontalAlignment="Left" Margin="100,245,0,0" VerticalAlignment="Top" Maximum="300" Minimum="10" Width="295"/>
        <TextBlock HorizontalAlignment="Left" Margin="263,268,0,0" TextWrapping="Wrap" VerticalAlignment="Top" Text="{Binding Value, ElementName=slider}" />
        <TextBox HorizontalAlignment="Left" Height="23" Margin="100,217,0,0" TextWrapping="Wrap" Text="תיבת טקסט לכתיבה חופשית" VerticalAlignment="Top" Width="{Binding Value, ElementName=slider}"/>
        <TextBox HorizontalAlignment="Left" Height="23" Margin="100,189,0,0" TextWrapping="Wrap" Text="{Binding Value, ElementName=slider, Mode=TwoWay}" VerticalAlignment="Top" Width="295"/>
    </Grid>
</Window>

תריץ את הפרוייקט ותראה שתנועת הסליידר משפיעה על רוחב הטקסט בוקס, ועל הערך שיש בטקסט בלוק מתחתיו. כמו כן תיבת הטקסט העליונה יכולה לקבל ערך מ 10 עד 300 ולאחר לחיצה על TAB היא תשפיע על כל האלמנטים דרך הסליידר.
תבדוק ישר והפוך ותראה שאין שום קוד C# מאחורה, שום אירוע כלום!!!
הרעיון הוא פשוט, המאפיינים של האלמנטים הללו הם "חכמים" ולא מוחלטים, הם כרוכים לערכו של הסליידר (הטקסט בוקס העליון, כרוך דו צדדית לסליידר ולכן כשערך הסליידר משתנה גם הוא משתנה וכשערכו משתנה גם ערך הסליידר, וזה משפיע כל על ההקשרים)

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

איינשטיין לא אמר פעם
"מה שמעניין בעולם אלו הנוסחאות, ולא המספרים, חוץ ממהירות האור שהיא כפופה למספר מוחלט"

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

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

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

בהצלחה.

פורסם במקור בפורום CODE613 ב18/07/2013 01:26 (+03:00)

פעם ראשונה שאני שומע על WFA מה זה מי זה מו זה??? לינקים הסברים???

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

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

בהצלחה.

פורסם במקור בפורום CODE613 ב17/07/2013 23:59 (+03:00)

מסכים עם כל מילה.
היה שווה.......

פורסם במקור בפורום CODE613 ב17/07/2013 23:55 (+03:00)

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

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

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

פורסם במקור בפורום CODE613 ב16/07/2013 17:52 (+03:00)

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

פורסם במקור בפורום CODE613 ב05/01/2014 00:46 (+02:00)

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

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

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

פורסם במקור בפורום CODE613 ב16/07/2013 23:37 (+03:00)

שלום לכולם

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

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

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

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

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

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

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

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

אז אחרי כל הפילוסופיות אפשר להתחיל.

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

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

1. כל ערך שמוקלד אי פעם נכנס לרשימה והופך להיות חלק ממנה. שיטה זו בעיני היא נלוזה ועקלקלה, ואין בה שמץ של ארכיטקטורה, כבר עדיף לעבוד עם אקסל, הוא באמת נותן השלמה אוטומטית לכל מה שיש מעליו.
2. לעשות טבלה מיוחדת לכל combobox שיכיל את הערכים שלו (בדרך כלל באמצעות key-value דהיינו ID ו string) ככה יש לנו שליטה מלאה בחומר.
3. טבלה אחת גדולה שתכיל את כל הערכים של כל ה combo בתוכנה, עם שדות שתפקידן לסנן את הערכים שלא יתערבבו קומבו בקומבו.

דוגמא נוספת יותר קיצונית:
יש לנו תנועות פיננסיות מכל מיני סוגים, הוראות קבע, שיקים, מזומנים, העברות בנקאיות, שוברים, ועוד הרבה, וכל זה תכפילו בשניים לפחות הוצאות והכנסות (יש גם זיכויים וחיובים אבל הבה ונעצור כאן) שוב יתווכחו המתווכחים, יש שיעשו טבלה לכל נושא, טבלה להכנסות בהוראות קבע, טבלה להכנסות בשיקים, טבלה להכנסות במזומנים, שוברים, העברות, וכן להוצאות, כעת מה יהיה אם יש לנו תרומות ושכר לימוד??? האם צריך טבלאות נפרדות לשכר לימוד, ולתרומות? אפשר להגיע במוסד ממוצע ל 30 טבלאות בלי גוזמא, אם ניצמד לעיקרון שכל נושא הוא טבלה בפני עצמה.
השיטה האחרת אומרת, טבלה אחת גדולה של הכנסות, כאשר השדה "אופן הכנסה" אמור להצביע על סוג התנועה, באיזה אופן בוצעה. בהוראת קבע או בשיק וכדומה.
שיטה יותר קיצונית אומרת, טבלה אחת גדולה שתכיל גם את ההוצאות וגם את ההכנסות, ויהיה שדה שיגדיר Type האם מדובר בהוצאה או בהכנסה, שדה נוסף שיגדיר את אופן התנועה (וכאן אנו חוסכים ב combo וב UI ובניהול של קוד!!!! כי הכל בטבלה אחת וממילא גם מבנה אחד בקוד)

בשיעור הבא נדבר באיזו שיטה צריך לבחור.

בהצלחה לכולם!

פורסם במקור בפורום CODE613 ב15/07/2013 13:02 (+03:00)

אני לא יודע איך לבדוק זאת.

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

פורסם במקור בפורום CODE613 ב18/07/2013 12:00 (+03:00)

שוב שלום למנהל הפרוייקט.

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

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

פורסם במקור בפורום CODE613 ב13/07/2013 21:52 (+03:00)

קודם כל 625 שעות זה לא חינם!!! זאת השקעה אדירה מצידך.

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

שמח שהצטרפת לקהילת המתכנתים בהצלחה.

פורסם במקור בפורום CODE613 ב16/01/2014 11:10 (+02:00)

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

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

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

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

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

כעת ניצבת בפניך משימה של בחירת שפה, וזאת החלטה לא פשוטה, כי השפה שתבחר עכשיו היא תהיה השפה שלך לשנים הקרובות, לאחר מכן יהיה קצת קשה להגר לשפה אחרת, מהרבה סיבות, מנטליות וכלכליות. אז זה נושא בפני עצמו וכדאי שתחליט עליו לפני שאתה מתחיל. אני אישית הייתי ממליץ לך ללמוד שפות אינטרנטיות, ובכלל לפתח הכל רק בשפות של דפדפן, זה אומר HTML JavaScript בצד הלקוח, ו PHP או NodeJS בצד השרת (תבדוק בויקיפדיה ותבין מה המשמעויות) זה אמנם יותר קשה ללמוד מאשר דוט נט, אבל יש יתרון עצום ונורא למי שיודע את השפות הללו. אני היום כבול באקסס, דוט נט וגרורותיה, ולומד את שפות הדפדפן, זה מאוד קשה להגר זאת תפיסה אחרת לגמרי יעיד על כך דוד ל.ט. שלא עלתה בידו, אבל העתיד נמצא שם.
לגבי מסדי נתונים יש את MySQL שהיא קוד פתוח וחופשי, ויש את SQL Server מבית Microsoft וכאן שוב אתה נכנס לשאלת השאלות האם ללכת עם Microsoft או עם תוכנות קוד פתוח. אני כבר הכרעתי שעדיף קוד פתוח, ודוד ל.ט. הכריע שעדיף מיקרוסופט, כל אחד מסיבות אישיות, פרקטיות, דתיות, או לא משנה מה. אתה גם צריך להכריע וכדאי לך לעשות את זה מוקדם, כדי שלא תתחרט אחר כך.

בכל מקרה איחוליי להצלחתך ותעשה חיל!

פורסם במקור בפורום CODE613 ב11/07/2013 11:17 (+03:00)

קצת רקע לפני שאני עונה:

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

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

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

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

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

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

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

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

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

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

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

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

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

פורסם במקור בפורום CODE613 ב10/07/2013 22:33 (+03:00)