21 מגמות תכנות חמות - ו 21 מתקררות

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

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

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

חם: מעבדים מקדימים

לא: ערימות שפה מלאה

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

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

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

חם: ללא שרת

לא: דוקר

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

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

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

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

חם: מסגרות MV * של JavaScript

לא: קבצי JavaScript

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

יש כיום עשרות מסגרות כמו קנדו, סנצ'ה, jQuery Mobile, AngularJS, Ember, Backbone, Meteor JS, ורבים אחרים, כולם מוכנים להתמודד עם האירועים והתוכן עבור יישומי האינטרנט והדפים שלך.

אלה בסך הכל אפליקציות האינטרנט. יש גם מספר שמכוון להציע פיתוח בין פלטפורמות לעולם הסמארטפונים / טאבלטים. טכנולוגיות כמו NativeScript, PhoneGap, Apache Cordova ו- React Native הן כמה מהאפשרויות ליצירת אפליקציות מתוך טכנולוגיית HTML5.

חם: מסגרות CSS

לא: CSS גנרי

פעם, הוספת קצת pizzazz לדף אינטרנט פירושה פתיחת קובץ CSS וכולל פקודה חדשה כמו font-style:italic. ואז שמרת את הקובץ והלכת לארוחת צהריים לאחר עבודה קשה של בוקר. כעת דפי אינטרנט כל כך מתוחכמים שאי אפשר למלא קובץ בפקודות פשוטות כל כך. צביטה אחת לצבע והכל יוצא מגדרו. זה כמו מה שאומרים על קונספירציות ואקולוגיות: הכל מחובר ביניהם.

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

חם: SVG על בד

לא: פלאש

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

כעת, כאשר לשכבת JavaScript יש את היכולת לעשות הרבה מאותו הדבר, יצרני ומפתחי הדפדפנים מריעים לסוף הפלאש. הם רואים שילוב טוב יותר עם שכבת DOM המגיעים מפורמטים חדשים כמו SVG (Scalable Vector Graphics). ה- SVG וה- HTML כוללים ערימה גדולה אחת של תגים שלעתים קרובות קל יותר לשימוש עבור מפתחי אתרים. ואז יש ממשקי API גדולים המציעים ציור משוכלל על אובייקט הקנבס, לרוב בעזרת כרטיסי מסך. הרכיבו אותם ונשארו לכם מעט סיבות להשתמש יותר בפלאש.

חם: נתונים גדולים כמעט (ניתוח ללא Hadoop)

לא: נתונים גדולים (עם Hadoop)

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

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

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

חם: ניצוץ

לא: Hadoop

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

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

חם: תצורת מסד נתונים

לא: תכנות תוכנה

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

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

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

חם: מסגרות משחק

לא: פיתוח משחקים מקומיים

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

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

חם: מחוללי אתרים סטטיים

לא: אפליקציות אינטרנט של עמוד יחיד

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

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

חם: GraphQL

לא: לנוח

זה לא כאילו REST מת. רק שאנחנו רוצים לעשות יותר עם ה- API, ו- GraphQL היא דרך לעשות זאת. GraphQL מחזיר את הנתונים ב- JSON, בדיוק כמו REST. GraphQL מתחיל עם HTTP POST, בדיוק כמו שיחות REST רבות. רק שתחביר GraphQL מאפשר לך לציין שאילתות מורכבות מאוד עם כמה הקשות. זה עושה את זה פשוט יותר עבור מתכנתים לבקש בדיוק מה הם רוצים, וזה מפחית את כמות העבודה בצד השרת שיש לעשות כאשר מישהו רוצה ממשק API שונה במקצת.

חם: ענני IDE

לא: מזהים מקומיים

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

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

חם: GPU

לא: מעבד

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

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

חם: GitHub

לא: קורות חיים

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

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