ק
@האדם-החושב
אני אנסה להסביר בקצרה מה אתה צריך לעשות.
א. להתקין שרת מונגו לוקאלי על המחשב, אפשר להוריד מפה.
(כדי לבדוק אם אכן השרת פועל על המחשב אפשר להיכנס לדפדפן בכתובת http://localhost:27017/ ולראות אם הדף עובד ומציג טקסט כלשהו זה אומר שהשרת רץ על המחשב)
ב. לבצע ייבוא של החומר למסד הנתונים (mongorestore --drop)
ג. אני ממליץ לך להוריד את compass שזה ממשק גרפי לניהול מסדי נתונים של mongo, שם תוכל לראות את הנתונים וגם לעשות יבוא ויצוא בצורה נוחה.
בפתיחת התוכנה תיצור חיבור לשרת הלוקאלי ככה:
אני לא יודע איך bat to exe עובד (כי אני בחיים לא מקמפל סקריפטים), זה יכול להיות בשני דרכים, או שהוא ממש מקמפל את הסקריפט לקוד בינארי, או שהוא פשוט יוצר wrapper כלשהו לסקריפט המקורי, ובשעת ההרצה הוא שומר אותו בתקיה זמנית ומריץ אותו מה-cmd. אם הדרך הראשונה היא הנכונה אז אין אפשרות להגיע לקוד המקור.
מדברי @yossiz עולה שהוא הבין (הוא שהוא יודע) שזה פועל כמו האפשרות השנייה, אז אם כן האפשרות הנכונה זה להשתמש בכלי בערפול לסקריפט עצמו, מרפרוף מהיר נראה שיש כמה כלים שעושים את זה, לדוג' Bat2Exe (נראה שהוא גם ממיר ל-exe וגם מערפל את הסקריפט).
@אוריי כתב בחלום \ אתגר | זיהוי ראשי תיבות של סימני מקורות בקבצי וורד:
יש ראשי תיבות סתמיים במסמך
אפשר לזהות ר"ת שהם לא יכולים להיות סימן ולהתעלם מהם.
לדוגמא: המילים אע"פ או שו"ת לא יכולים לייצג שום מספר בגימטרייה, אז זה ודאי ראשי תיבות שצריך להתעלם מהם.
אפשר לכתוב קוד שיזהה האם ר"ת כלשהוא יכול לייצג מספר או לא.
@אף-אחד-3
אני חושב שהיתרון היחיד ברשימות האשים זה רק אם הם ממוינים בסדר עולה או יורד, כי אז אפשר לחפש ערך מסויים של האש בקובץ בעל אולטרה נפח עם טריליוני האשים, ובגלל החיפוש הבינארי התוצאה תהיה מאוד מהירה.
אבל בכל מקרה היום זה לא כל כך יעיל, מכיון שמשתמשים עם 'המלחה' לפני שמחשבים את ההאש, אז זה אמור לתת הגנה מפני רשימות ההאשים ופריצות באמצעות ה-Rainbow Tables שהזכיר @yossiz.
@אף-אחד-3 כתב במה האלגוריתם ליצירת ההאש לסיסמה בווינדוס ?:
@קומפיונט למה לא מבין ? חיפוש ברשימה אמור להיות (ככה אני חושב בכל אופן) הרבה יותר מהיר מאשר חישוב של כל ההאשים לסטרינגים אפשריים בכל פעם מחדש
אני עדין לא בטוח שזו הסיבה.
אני אשאל שאלה רטורית: כמה זמן לוקח להכין את קובץ ההאשים הזה?
בכל מקרה ככל שיגדל הזמן להכין את קובץ ההאשים ככה יגדל הזמן הנדרש להעביר אותו ממחשב למחשב. אז איפה היתרון?
@אף-אחד-3 כתב במה האלגוריתם ליצירת ההאש לסיסמה בווינדוס ?:
@קומפיונט התחיל מכאן והמשיך בשביל האתגר
אבל אני עדין לא מבין מה התועלת ברשימה של האשים?
אם נגיד רוצים לבדוק ערך מסוים במהלך brute force אז לוקחים את הערך, מחשבים את ההאש שלו ואז עושים השואה.
מדוע צריך רשימה מוכנה של כל ההאשים?!
@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:
אם האלמנטים ברשימה הם לא פרימטיביים (כלומר Reference Type) ברור כשמש שתוכן הפריטים לא משוכפל. הנושא הוא הרשימה עצמה, נוצרת רשימה נוספת. כל רשימה זה מערך בזיכרון, גם שההתייחסות הם לאותם אובייקטים.
אז מה היתה ההוא אמינא ש-ToList לא משכפל?! ההו"א היתה ש-ToList מתנהג כמו Enumerator?
אני מסכים עם דברי @yossiz כי ברגע שיש לפורץ גישה ל-Hash אז משמע שהוא כבר עם הרשאת מנהל. כי למשתמש רגיל אין גישה (לכאורה) למקום הזה.
אבל בכל אופן זה באמת נראה שיטה גרועה למדי, אבל מיקרוסופט כותבים שהם משתמשים ב-LM לצורכי שמירה על תאימות לאחור עם חומרה ותכנה ישנים שלא יכולים בדרכים יותר חדשות.
The LM OWF algorithm is included in Windows for backward compatibility with software and hardware that cannot use newer algorithms.
אם אני מבין נכון אז הדוגמא ש @dovid הביא ממחישה שכשקוראים ל-Last אז אם האובייקט של הרצף ממש את IList`1 אז ישר מתבצע קפיצה לאינדקס האחרון, ואם לא אז ה-Last עובר ו'מעיר' את כל הרצף עד שחוזר false מה-()MoveNext.
אם הבנתי נכון אז אפשר לראות את זה ב-ILSpy:
אגב, בדקתי, ToList לא משכפל את הרצף, הוא רק יוצר Reference חדש לערכים הקיימים.
עריכה: אפילו המתודה CopyTo ב-List`1 משכפלת רק את ה-Reference.
@yossiz כתב במה האלגוריתם ליצירת ההאש לסיסמה בווינדוס ?:
(נראה לי ש-DES נחשב היום ממש חלש, יש את 3DES שיותר טוב)
הערת אגב, היום ה-AES נחשב המקום הראשון של ההצפנות הסימטריות.
@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:
א. ToList מצריך לולאה + משתנה. זה הרבה יותר משמעותי מלולאה נטו.
למה ToList חוסך לולאה ומשתנה? זה לכאורה עושה return new List<TSource>(enum)
ג. הנקודה היא לא מה חוזר. קוראים לזה תכנות פונקציונלי.
פונקציה שנכתבה לפי כללי התכנות הפונקציונלי בהכרח תחזיר ערך כי אחרת מה היא עושה, כי מה שקורה בגוף הפונקציה חייב להיות פרטי ובלתי נוגע לשום דבר אחר בעולם מלבד פלט.
אולי בגלל שלא מובן לי עד הסוף מה זה 'תכנות פונקציונלי' אז אני לא מצליח להבין מדוע חייב לחזור ערך. אין כזה דבר בתכנות פונקציונלי שחוזר ערך void?
הפילוספיה היא שזה מתודות שאפשר להשתמש בהם בבטחה בלי לחשוש שהם ישפיעו על חלקים אחרים בתכנית שלך. לעולם לא יקרה שינוי לחלק בתכנית מפעולת LINQ שלא הושמה לתוך משתנה. בתוך המתודה ToList או ToArray קורה מה שקורה, אבל זה בסקופ סגור ובלתי משפיע, וזה יוצר פלט שאתה בוחר איך להשתמש בו.
לכאורה המתודה ForEach שומרת על הכלל הזה, מכיוון שהיא לא תוכל לשנות ערכים כל שהם, (הייעוד שלה זה לעשות פעולה חיצונית עבור כל אחד מהערכים) היא אמנם תוכל לשנות מאפיינים בתוך ערכים, אבל זה גם בעיה שנמצאת ב-Select וב-Where אם כי זה לא הייעוד שלהם, אבל הם לא מספקים את ההגנה הזאת.
אני מבין במקצת את הרעיון של ההגנה מפני שינוי על הערכים ברצף, אבל מדוע זה כלל גורף ב-LINQ? למה שלא יהיה אפשר לעשות שינוי למאפיינים באמצעות LINQ? יכול להיות שזה בהחלט הסיבה שגרמה למפתחים של LINQ לא להכניס כזאת פונקציה.
@dovid
אכן קראתי התשובה הוא מסביר שם נפלא למה ForEach אין מקומו ב-LINQ.
אבל עדיין יש כמה תמיהות כדלהלן:
בקשר לטענות הכותב:
א. למה דווקא ForEach מיותר וכי ה-ToList לא מיותר?! אדרבה, בעידן הנוכחי שהתכנות הפונקציונלי די פופולרי, קטע הקוד הבא יכול להיות מאוד אלגנטי:
Enumerable.Range(1, 20)
.Select(n => n * 3)
.Where(n => n % 2 == 0)
.DoForEach(n => Console.WriteLine(n));
הדרך המקבילה ב-foreach אמורה להיות קצת יותר מעצבנת... ובפרט כשהשרשור של האופרטורים יותר ארוך מהדוגמה.
ב. כנ"ל.
ג. זה באמת הנקודה שהכי דגדגה לי, כי היות והערך המוחזר מ-ForEach הוא void יוצא שהיא המתודה היחידה שלא מחזירה ערך כלשהו. אבל גם על זה אפשר להתפלסף, כי הרעיון של ForEach זהה לרעיון של ToList ו-ToArray אלא שספציפית הפעולה של ForEach לא אמורה להחזיר ערך כלשהו.
וחוץ מזה מדוע העיקרון הגורף של LINQ הוא להחזיר ערך כלשהו? למה לא להשתמש איתו כדי להשפיע על הרצף בלי להחזיר שום ערך? איזה דבר רע (או לא פילוסופי) יש בזה?!
ועוד משהו, הכותב הנזכר בעצמו מעלה פה בסוף המאמר טיעונים חזקים המפריכים (במקצת) את התיאוריה שהוא כתב, ויש לציין שהטיעונים הללו נותרו ללא תשובות.
@dovid כתב בלמה DoForEach לא קיים ב-LINQ?:
גם אני לעיתים מתחשק לי ForEach כמתודה במקום בלולאה, אבל אני לא מוצא לזה ייתרון שכלי, זה סה"כ נטיה רגשית לזרום יותר מידי עם תכנות פונקציונלי.
אני מסכים עם דבריך, אבל לפי זה מדוע המפתחים טרחו לכתוב את ההרחבה ()ToList?! לכאורה גם לה אין שום יתרון שכלי. כי אפשר לקבל את אותה התוצאה באמצעות הכתיבה הזאת:
var list = new List<int>(enumerable)
@חגי תודה על התשובות המקצועיות.
אני לא יודע אם Enumerable ו-LINQ קשורים בהכרח אחד לשני, אבל בכל מקרה יש הרבה הרחבות במחלקה Enumerable שלא מקיימות את התנאי הזה, קח לדוגמא את ()ToArray שזו נטו חיסכון בקוד. אז אם כן שאלתי עדין במקומה עומדת מדוע 'חסרה' פונקציה שתעשה איטרציה על כל הרצף?
זה שיש את זה ב-List זה מחזק את השאלה מדוע לא הוסיפו את זה גם ל-Enumerable כמו שלדוגמה ()ToArray מופיע בשניהם.
ודרך אגב, הרעיון המרכזי ב-LINQ הוא להפסיק לכתוב "איך" ולהתחיל לכתוב "מה", וגם לפי זה ההיגיון הפשוט הוא היה להוסיף פונקציית עזר כדוגמת ForEach.
שאלה שמנקרת בראשי הרבה זמן.
המחלקה Enumerable ב-dotnet עשירה בעשרות פונקציות שמקילות על הפיתוח וחוסכות כתיבת קוד.
אבל אני תוהה מדוע 'חסרה' שם פונקציה פשוטה? אפשר לקרוא לה לצורך הדוגמא DoForEach שתעבור על כל הרצף ותעשה פעולה זהה לכל אחד מהערכים.
במקום לעבור על זה בלולאת foreach אפשר לקרוא לפונקציה פשוטה שתקבל את ה-action בארגומנט.
אני לדוגמא בכל פרויקט מוסיף את ההרחבה הזאת:
public static class EnumerableExtensions
{
public static void DoForEach<T>(this IEnumerable<T> source, Action<T> action)
{
foreach (var item in source)
{
action(item);
}
}
}
יש למישהו הסבר מניח את הדעת מדוע מפתחי LINQ בחרו שלא לכלול פונקציה כזאת ב-LINQ.