היי,

בעקבות כל מיני שיחות שהיו לי עם כמה אנשים, מעניין אותי לשמוע את דעתכם -

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

אני מדבר לדוגמא על jQuery , bootstrap , angularJS, nodeJS
ומערכות לבניית אתרים כדוגמאת וורדפרס, WIX וכו'.

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

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

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

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

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

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


המשך ערב טוב,
וחג חנוכה שמח

נגד!
הכי כיף לבזבז אינסוף זמן לממש שטויות מאפס כמו נכה!

ברור לך שיש דברים שחייבים בשבילם צד שרת, ויש דברים שחייבים בשבילם צד לקוח?

ציטוט:

במקור נכתב על ידי Benjamin Willard נגד! הכי כיף לבזבז אינסוף זמן לממש שטויות מאפס כמו נכה!

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

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

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

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

ציטוט:

במקור נכתב על ידי Benjamin Willard ברור לך שיש דברים שחייבים בשבילם צד שרת, ויש דברים שחייבים בשבילם צד לקוח?

אני לא מדבר על היכולת לבצע פעולות בצד לקוח/שרת. אלא ה"ממשק".

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

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

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

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

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

לגבי מה ששאלת על צד שרת/ צד לקוח...
כנראה בגלל שאני בא מהכיוון של פיתוח תוכנה (צד שרת ו pc), אני מרגיש מאוד בנוח עם thick clients ובווב זה single page apps וכד', ולעשות דיי הרבה על הקליינט... וזה גם הכיוון של רוב האתרים המודניים...

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

שוב, מה שיותר קל...

בעבודה זה בד"כ: "אני אתן לכם service שמדבר ב xml / json , ואתם תעשו איתו מה שבא לכם"

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

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

עריכה: עכשיו אני רואה שיצאה כאן חפירה רצינית. אז מצטער מראש!


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

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

אז מה שאני רואה זה אתרים שבברירת מחדל שלהם כבר שילבו -
jquery
jquery.ui
bootstrap
bootstrap-rtl
animate

בנוסף, עוד קובץ CSS וקובץ JS של המתכנת.

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

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


---

דוגמא אחרת, לעניין הוורדפרס -

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

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

---

ודוגמא אחרונה לעניין ה"ממשק" -

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

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


---

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

ומעבר לכך -
מעניין אותי לדעת, אם מי שבוחר לבנות אתרים בצורה כזאת, ידע בעת הצורך לבנות גם אתרים רגילים בלי להשתמש בכלל בכל הספריות/ההרחבות האלה?
כי אני רואה הרבה מתכנתים ואפילו חברות שמצהירים "אנחנו נבנה לך אתר בוורדפרס!",
או "אנחנו עובדים עם bootstrap כדי לבנות לך את האתר".
והשאלה היא, האם הם יודעים גם לבנות אתרים אחרים בלי זה? או שבבסיס הם למדו שככה בונים אתרים וזה כל מה שהם יודעים?


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


/סוף חפירה. (מצטער על זה חחח)

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

ברור ש (KISS (Keep it simple stupid זה חשוב, וחבל לסחוב דברים שאתה לא צריך ולעשות דברים בצורה מסובכת, ולו בגלל הביצועים...

ובלי קשר ביצועים זה requirement לכל דבר שצריך להתחשב בו...

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

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

ציטוט:

במקור נכתב על ידי Benjamin Willard אתה יודע שיש כלים בשביל לצמצם את ה js ו css שלך רק למה שאתה צריך נכון? חוץ מזה שקשינג וזה...

אני מכיר את הכלים שעושים minify לקבצים וכו',
מה זה "כלים בשביל לצמצם רק למה שאתה צריך"? אשמח להכיר.

לגבי קשינג, 2 דברים:

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

ציטוט:

במקור נכתב על ידי Benjamin Willard ברור ש (KISS (Keep it simple stupid זה חשוב, וחבל לסחוב דברים שאתה לא צריך ולעשות דברים בצורה מסובכת, ולו בגלל הביצועים... ובלי קשר ביצועים זה requirement לכל דבר שצריך להתחשב בו... אבל... הפתרון הכי טוב לבעיה בעולם התוכנה זה תמיד - מה שעונה על הדרישות, הכי פשוט, והכי קל לתחזוקה לאורך זמן, ובסדר הזה...

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


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

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

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

will you marry me nesli barda? Operating system: Linux The day Microsoft & apple makes a product that does not suck will be the day they start making vacuum cleaners. say no to Apple&Facebook&MS&Samsung IL&Nokia&Hot&Yes,but say yes to Google

ציטוט:

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

כי אני לא מוצא את זה מורכב כל כך לכתוב משהו כזה -

(בלי שום ספריה חיצונית)

קוד:

<div id="myelement" onmouseover="doSomething()">bla bla

(או רק עם jQuery, אפשרות אחת מיני רבות)

קוד:

$("#myelement").on("mouseover", function(){
   // do something
});

או אם זה רק שינויים עיצוביים, אז כמובן שעדיף CSS

קוד:

#myelement:hover {/* change something */}

ושלא לדבר, כמובן, על זה שפחות קוד = האתר שוקל פחות = פחות תעבורה = יתרון.

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


ועכשיו העלת את העניין הכלכלי!
ובדיוק בגלל זה באה השאלה שכתבתי בהודעה הראשונה:

ציטוט:

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

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

ציטוט:

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

מה זה "אם מצאת וורדפרס עם מערכת אחורית / טמפלט בלי מערכת אחורית"?
לא הבנתי את הניסוח הזה.

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

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


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

יש עוד אינסוף:
https://developers.google.com/speed...MinifyResources

אז כמו שאמרתי, אני מכיר את הכלים ל minify.
חשבתי שהתכוונת למשהו אחר.

ועדיין, יש הבדל בין "לכווץ" אלף שורות קוד או 100 שורות קוד.

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

*תלוי במלא דברים, והמדד עצמו בעייתי מאוד.

אתה מדבר על תוכנה בכללי? או על בניית אתרים?

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

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

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

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

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

עכשיו אתה מבין איך אפליקציה שבסה"כ מממשת Wiki מצליחה לתפוס 1GB RAM? (אני מדבר על מוצריה זוללי המשאבים של חברת Atlassian, שמאוד אהובים בעולם הפיתוח) - ולמרות כל זאת (מפתחי Java טוענים שצריך להחזיק "הכל" בזיכרון, אפילו שכל ה DB של האפליקציה הזו לא תופס כ"כ הרבה על הדיסק - כי גישות "מטומטמות" כגון "shared nothing" הן "הרבה יותר איטיות") - ונוטה לעבוד הרבה יותר לאט מכל מוצר Wiki שאינו כתוב ב Java[*] ?


[*] לא בדקתי מוצרי Ruby. מסכים מראש לא לכלול אותם בהשוואה.

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

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

האמת שתמיד העדפתי דברים כמו trac ...

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

ואותו דבר עובד ב JS. וכשאתה משתמש ב CMS כדי להריץ בלוג. וכשאתה משתמש בתוכנת בלוג כדי לעשות CMS/אתר E-Commerce. וכן הלאה...

אני לא נגד שימוש בספריות או מערכות מוכנות (היי, תראה על מה מבוסס האתר שאתה כותב בו!). אני נגד ביצוע abuse ואי התחשבות ב response time למשתמש, שהוא דבר די קדוש בעיני.

נמאס לכם לזכור סיסמאות? לחצו כאן!

בחייך שימי...

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

Shared nothing זה לא מושג רלוונטי במקרה הזה...

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

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

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

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

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

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

shared nothing זה מאוד רלוונטי. זה ההבדל בין לטעון לזיכרון ולבצע מה שאתה באמת צריך, לבין "אפליקציית ענק שטעונה בזיכרון, ובפועל, משתמשים אולי ב 1% מהמידע ומהפונקציונליות שיש אליהם רפרנס אליה איפשהו". כמו לטעון jQuery כשהדבר היחיד שיש לך בדף זו קריאת AJAX אחת (סתם לדוגמה - מצטער שאני קופץ פתאום לצד לקוח, אבל זה קלאסי...), או יותר גרוע, משהו פשוט יותר כמו שינוי של אלמנט DOM בודד כשלוחצים על כפתור, כאשר היה אפשר לעשות את זה ישירות, או, יותר גרוע, על ידי שימוש ב CSS בלבד...

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

אני לא אומר ש TTM אינו חשוב (אבל הוא לא קדוש. הקטע שהכי מטריף אותי בעולם הוא כשיש משהו חמור במערכת, ויודעים שיקח עוד יומיים לעשות אותו טוב, אבל משחררים אותו עם הזבל בפנים רק כדי לעמוד באיזה תאריך שרירותי שמישהו קבע בהתבסס על בערך שום דבר - ואחרי זה לקבל ריקושטים בכמויות, ולהוציא גירסה חדשה שתטפל בנזקים של הגירסה שקודם הוצאת, ולעבוד על זה חודש! שכמובן דוחה את ה TTM של הגירסה הבאה בחודש; כמובן שיתחשבו בזה בתאריך השרירותי הבא שיקבעו, שהרי, מתחילים לעבוד על הגירסה הבאה מאוחר יותר, וזו בדיוק הנקודה שלי...) - אני כן אומר שהגישה הזו לא משפרת את ה TTM לדעתי, וייתכן שלאורך זמן אפילו פוגעת בו, לעתים קשות. כל מה שכתבת על דברים מסביב זה חרטא, ולא קשור לדברים שאני מדבר עליהם בכלל. כאילו שיש מי שכותב ב Java ולא משתמש בקופי-פייסט מ SE ב: log4j, JDBC, HttpClient וכו' (אגב, נכון שכיף לעשות SSL עם HttpClient? הרבה יותר מהמימוש של cURL...) בשביל לבצע את הכל. אני לא מדבר על ה"בסיס" של שפת התכנות שצריך להיות חלק מהשפה והוא לא רק בשם איזה עקרון תאורטי. אני מדבר איתך על ספריות ספריות. כאלה שאתה מנסה לפתור משהו ב "business domain" שלך, כדבריך, אז אתה מחפש בגוגל, מוצא משהו שעושה משהו דומה, ואז מנסה לכפות עליו לממש את ה business domain שלך. וכולם עושים את זה... לפחות ב Java.

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

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

https://en.m.wikipedia.org/wiki/Sha...ng_architecture

אז הוספת את המילה "architecture", סוג ספציפי של shared nothing, ואז אתה אומר שאין קשר, למרות שאני לא דיברתי על ארכיטקטורה (במובן של ארכיטקטורת scale-out), שזו תוספת שאתה הוספת, אלא על העיקרון של אי צורך שבקשות שונות לאותו שרת יקבלו שאריות מפעילות קודמת של המערכת (בין אם זה חיבורים ל DB, זבל בזיכרון שעדיין לא נוקה ואולי לעולם לא ינוקה, וכו'), אלא שיעבדו בצורה שבה כל בקשה היא "דף חלק", ולכן ברור מאוד איך המידע שלך נראה. ההבדל בין שתי שיטות העבודה ניכר בפועל (לפחות למי שלא עוצם עיניים מול המציאות) : זה ההבדל בין אפליקציות שתמיד עובדות באותה צורה, לבין כאלה שבהן אתה יכול לטעון את אותו דף עם אותם פרמטרים בדיוק, ולקבל תוצאות שונות. משום מה זה יותר פופולארי באתרים מבוססי .NET (לא יודע למה; אולי מתכנתים יותר גרועים בממוצע ממתכנתי Java?) - אבל כשאתה רואה דיאגרמת מצבים שבה האתר מגיב אבל נותן הודעת שגיאה (Exception על מידע שהגיע לא נכון למתודה) -> אתה לא נוגע בשום קוד באתר -> אתה עושה Restart לסרביס -> האתר חוזר לעבוד, וממשיך לעבוד זמן אקראי שוב (יכול להיות אפילו חודש!) עד שזה חוזה חלילה - זה העניין שעליו אני מדבר.

נמאס לכם לזכור סיסמאות? לחצו כאן!

לא...
המשמעות של shared nothing היא שונה...

לדוגמה אתרים עם DB הם בדכ לא shared nothing

טענה מעניינת...

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

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

המשמעות של ארכיטקטורת shared nothing (למרות ששוב, לא דיברתי על זה, דיברתי על מה קורה בתוך שרת בודד בכלל!) היא שאין צורך בסנכרון בין "איים" שונים שבהם חיה האפליקציה - ואובדן של "אי" לא גורם לאובדן גישה למידע או בכלל לאובדן מידע, פשוט משום שכל המידע זמין בכמה מקומות שכל אחד מהם הוא self-sufficient. ברגע שהארכיטקטורה שלך כזו, אתה יכול לעשות scale-out אינסופי.

נמאס לכם לזכור סיסמאות? לחצו כאן!

תקשיב...

Shared Nothing זה מושג עתיק, מתחום מסדי הנתונים בכלל... הוא נולד עם שני מושגים משלימים: shared memory, shared storage :

- Shared memory (כארכיטקטורה למערכות מבוזרות) נפטר, ולאחרונה נולד מחדש.

- Shared storage זה בגדול מערכת שה nodes שלה תלויים ב DB משותף.

- Shared nothing זה מערכת שלא תלויה בשום דבר חיצוני. יכול להיות לה DB אבל הוא פרטי לכל Node .

רוב המערכות המבוזרות בימינו עושות משהו בין שתי ההגדרות האחרונות, ורוב המערכות הקטנות הן shared storage


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

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

נכון שגישה כזאת עלולה ליצור בעיות כמו: בעיות סנכרון, race conditions, corruption , אבל בד"כ הכל סבבה. אישית יצא לי לעבוד על הרבה מערכות שנבנו ככה. וגם לעבוד טיפה על מערכת PHP שעבדה ככה והשתמשה ב Memcached .

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

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

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

למען הסר ספק, לא דיברתי על premature optimization.

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

לגבי רובי:
http://skillcrush.com/2015/02/02/37-rails-sites/

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

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

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

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

טוב אחי