7 מיומנויות עבור תהילה IT & Fortune

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

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

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

פיתוח אפליקציות אינטרנט:

אם אתה כותב יישומים להסתמך על לקוח כבד או מותקן, אני חייב להאמין שאתה ' סביר להניח שלא בחוד החנית של פיתוח היישומים. יישומי אינטרנט הם לאן התוכנה היא בראשות, עם מקף של SaaS ו PaaS (פלטפורמה, כמו שירות) כדי לאתחל. אספקת יישומים באמצעות דפדפן האינטרנט היא המקום שבו פיתוח יישומים מעניין ביותר קורה, בין אם זה עם יישומי ASP.NET, יישומי פורטל SharePoint, LAMP (לינוקס Apache MySQL PHP), ג 'אווה, או רובי on Rails. הוסף את היכולות המוצעות על ידי ספקי PaaS, כגון אמזון, Salesforce / Force.com ו- Google, ואת הדברים מקבלים די מעניין. ממשקי אינטרנט ביישומים יכול להיות דבר מצחיק. האם ממשק המשתמש באינטרנט הוא משהו שמופיע על גבי יישום מתוכנן היטב? האם עיצוב ממשק המשתמש של האינטרנט מוביל את שאר עיצוב היישומים? מה מתוכנן קודם, ממשק המשתמש האחורי או ממשק המשתמש הקדמי? ובכן, זה כנראה תערובת של שניהם, עם גורם אחד מאוד משמעותי נהיגה. 7 Habits פרודוקטיביות גורו סטיבן Covey אומר, "התחל עם הסוף בראש." סוג של הרעיון שאתה לא יכול ללכת לאיבוד אם אתה לא יודע לאן אתה הולך. התאמתי את דבריו של קובי:

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

מינוף וירטואליזציה:

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

המחזיק של גיליון זהב ב הבא Visor הירוק -> וירטואליזציה לא רק עבור מרכז הנתונים. כמפתח יישומים, תכנן כיצד תוכל למנף וירטואליזציה בארכיטקטורת היישום שלך, אפשרויות הפריסה, בדיקות היחידה ובדיקת QA. וירטואליזציה עושה עבור sandbox גדול בעת בדיקת רעיונות עיצוב, הדמיה תצורות הרשת והשרת, וטעינה של מספר גדול של סימולציה משתמשי קצה משתמשי. היתרונות של QA לבדם מהווים טיעון משכנע עבור חיסכון בעלויות של וירטואליזציה כפי שהוא עושה במרכז הנתונים. אם ה- QA וסביבות המעבדה שלך גדלות יותר במקום קטנות יותר, אתה עושה משהו לא בסדר. אם אתה מחפש מקום להתחיל לטבוע את השיניים שלך בווירטואליזציה, עבור להוריד את גרסאות החינם עבור Hyper-V, Xen, ו- VMware. תוכל לראות במהירות את הצורך יכולות ניהול הוסיף אבל דברים בחינם זה נהדר להתחיל עם.

SaaS מרובה דיירים ומדרגיות:

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

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

כתיבת קוד מאובטח:

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

כתיבת קוד מאובטח הוא יותר מאשר רק לדאוג לגבי התקפות overflure הצפת-מאגר או תנאי גזע. אתה כבר ברור עכשיו על ידי הנושא שלי עכשיו יותר ויותר יישומים הם יישומי אינטרנט, ויותר ויותר אלה גם הופכים יישומי SaaS במקרים רבים. התקפות אינטרנט הן בחוד החנית של הסיכונים שבהם יש ליישם נהלי פיתוח תוכנה טובים ומאובטחים. הזרקת SQL, Scripting בין אתרים, כתובות אתר של קסם וצורות נסתרות, מניעת דליפת נתונים, אבטחת שירותי אינטרנט ויישומים גרועים של SSL הם דוגמאות של בעיות אבטחה שעל פיתוח תוכנה לשקול ולהתאימם בעת כתיבת קוד מאובטח. אם אתה "מחפש מחדש כמה משאבים טובים כדי להתחיל את הנתיב של יצירת קוד מאובטח, אני ממליץ על שני ספרים 19 חטאים קטלניים של אבטחת תוכנה על ידי הווארד, LeBlanc ו Viega, ואת שירותי אינטרנט אבטחה על ידי או 'ניל.

אוטומציה QA וערכים:

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

רוצה להפוך את עצמך הכרחי כאדם QA? אוטומציה, אוטומציה, אוטומציה. הפרויקטים הטובים ביותר שעבדתי עליהם היו בדיקות אוטומטיות היטב לתוך 90% העליון, בדיקות היו לרוץ מאות ומאות פעמים לפני התוכנה נשלח. עכשיו, זה מה שאני קורא בדיקות רגרסיה! פונקציונליות חדשה עשויה להיבדק באופן ידני, אך הבדיקות היו אוטומטיות תמיד לפני שהתכנון נעשה במהדורה הבאה של התוכנה. זה בערך את הדרך היחידה CTOs וסמנכ"לים של הנדסה הם אי פעם לקבל כל לישון. עכשיו, לקחת את זה צעד אחד קדימה ולספק את עמיתים, מנהיגים טכניים וניהול עם למידה ותובנות אתה צובר מכל בדיקות כי תגיע למצב נירוונה בספר שלי. הידע הכלול בכל תוצאות הבדיקות האלה יכול לקחת אפילו את ארגוני הפיתוח הטובים ביותר לגבהים חדשים. CERTS, כל בברכה:

אני אוהב לומר:

אתה אף פעם לא יכול להשתבש עם CERTS. < זה הולך על מנטה נשימה כמו גם הסמכות טכניות. כולם אוהבים להתווכח על הערך של הסמכות: אם הסמכה + A מוערך; אם זה שווה לקבל MCTS לעומת הולך MCSE מלאה; אם יש CISSPs נושאת את אותו משקל זה עשה פעם; וכמה מנהלים מעריכים כל הסמכה על ניסיון בעבודה. אבל בסוף היום, זה יכול לעשות את ההבדל בין שאתה מקבל את העבודה על המועמד הסופי השני. ללא שם: קבלת אישור זה לא הולך לפגוע! CERTS להוכיח שיש לך להשיג משהו זה מראה לך רמה מסוימת של מיומנות, וזה הוכח על ידי הפגישה את הכישורים של הסמכה. הם לא בהכרח נותנים לך להטיס את המטוס, אבל אולי יש לך סיכוי טוב יותר להגיע למושב המשולב עם ארגון ה- IT. אתה תמיד מעדיף להיות יותר מדי יקר מאשר להפסיד, כאשר הזמנים הכלכליים קשים. אם ברצונך לקבל מידע נוסף על אישורי Microsoft, בקר בקטע הלמידה באתר של Microsoft לקבלת אישורים. אני ממליץ גם על כמה ספרי הדרכה הסמכה של Microsoft Press, כגון Windows Server Administration Kit Kit על ידי McLean, להגדיר את Windows Vista Client Kit Kit על ידי McLean, ואת Internet Information Services (IIS) 7.0 ערכת משאבים על ידי וולודארסקי.