הצמד הפיק לקליס את אלבומה הראשון, Kaleidoscope, בשנת 1999, וזכה להצלחה מסחרית עם שירים שהפיק לג'יי זי, מיסטיקל, באסטה ריימס ואשר.
בשנת 2001, הפיקו הנפטונז את השיר "I'm a Slave 4 U" של בריטני ספירס, איתו הגיעו לצמרת המצעדים ברחבי העולם.
באותה שנה הגיעו למקום הראשון בארצות הברית עם השיר, "Hot in Herre", של נלי.
הנפטונז הפיקו את אלבומם של הקליפס, Lord Willin', בשנת 2002. האלבום דורג במקום הרביעי במצעד האלבומים של הבילבורד.
הם הוציאו אלבום בכורה בשם The Neptunes Present... Clones, הכולל רמיקסים ושיתופי פעולה עם אמנים שונים, בשנת 2003.
הנפטונז הפיקו את השיר, "Drop It Like It's Hot" של סנופ דוג בשיתוף עם פארל, בשנת 2004. השיר הגיע למקום הראשון בשלושה מצעדי בילבורד (בילבורד הוט 100, בילבורד רית'ם אנד בלוז, בילבורד שירי ראפ) ובמצעדים נוספים ברחבי העולם. בנוסף, השיר היה מועמד לשלושה פרס גראמי.
הנפטונז זכו בשלושה פרסי גראמי מתוך 11 מועמדויות. הראשון בקטגוריית "מפיק השנה" והשני בקטגוריית "אלבום הפופ של השנה" על עבודתם באלבומו של ג'סטין טימברלייק, Justified, בשנת 2004.
הם קיבלו את פרס גראמי השלישי שלהם, בקטגוריית "שיר הראפ של השנה" על עבודתם בשיר "Money Maker" של לודקריס, בשנת 2008.
הצמד השתתף בהפקת אלבומה האחד עשר של מדונה, Hard Candy, באפריל 2008.
הקול של הנפטונז.
הקול של הנפטונז מאופיין בקטעי סינתיסייזר, סימפול קלידים ומלווה במכונת תופים.
רבים מהפקותיהם כוללים שירת פלסטו של פארל כמו בשירים, "Excuse Me Miss" של ג'יי זי ו- "Beautiful" של סנופ דוג.
.N.E.R.D.
N.E.R.D. הוא הרכב מוזיקלי הכולל את פארל, הוגו ואת שי היילי. שם ההרכב הוא ראשי תיבות של No one Ever Really Dies (אף אחד לעולם לא באמת מת).
ההרכב הוציא ארבעה אלבומים: In Search Of (2001),Fly Or Die (2004), Seeing Sounds (2008) ו-Nothing (2010).
בדיקות בארכיטקטורה מכוונת שירותים
בדיקות ארכיטקטורה מכוונת שירותים - ערך זה מתאר את עקרונות בדיקות התוכנה בארכיטקטורה מוכוונת-שירותים.
פיתוח בארכיטקטורה מוכוונת-שירותים מקל על מנהלי הארגון (חיסכון בעלויות פרויקטים), מאתגרת את עבודתם של המפתחים בארגון (אינטגרציה בין מערכות שונות), אך מקשה על עבודת הבודקים.
פיתוח בארכיטקטורה זו אומנם מוזיל בעלויות הפרויקט אך ללא יישום מתודולוגיית פיתוח נאותה עלול להגדיל את עלויות הפרויקט בשל הצורך במשאבים רבים על-מנת לבדוק את התהליך או המוצר הסופי.
על-מנת ליהנות מהיתרונות שבפיתוח בארכיטקטורה זו מוטל על החברה להטמיע ידע, מתודולוגיות וכלים מתאימים המוקדשים לבדיקות SOA.
בדיקות תוכנה בארכיטקטורה מוכוונת שירותים לעומת בדיקות תוכנה רגילות.
השוני העיקרי נובע מהיתרונות שהארכיטקטורה מציגה לתהליך הפיתוח - מהירות וגמישות.
היתרונות מושגים באמצעות תהליך של אי-צמידות, תהליך שמנסה לגרום לתלות נמוכה ככל האפשר בין המערכות השונות. התהליך גורר צרכים מיוחדים לפיתוח בארכיטקטורה מכוונת שירותים.
כדי להמחיש מהם בדיקות בארכיטקטורה מכוונת שירותים נראה דוגמה לתהליך של קניית מחשב באינטרנט. התהליך כולל צפייה בקטלוג המוצרים של החברה ובחירת המוצר. לאחר בחירת המוצר תהליך הרכישה מתבצע באמצעות web services. שירותי הרשת שישתתפו בתהליך יהיו: בדיקת זמינות המוצר במלאי, יצירת בקשת הרכישה ופרטי המשלוח לשירות אחר שיחשב את עלות המשלוח והעלות הכוללת של המוצר. לאחר חישוב העלות הבקשה תשלח לשירות שיקבע מספר הזמנה ייחודי במערכת ההזמנות לצורך מעקב וביצוע התשלום. משם יעשה שימוש בשירות שבודק בחברת האשראי את פרטי האשראי ומאמת שניתן לבצע את העסקה. כדי לבדוק את התהליך הנ"ל יש לבדוק את כל אחד מהשירותים בתהליך. כאשר יש לוודא שכל השירותים יודעים ל"דבר" אחד עם השני. למשל אם שירות אחד מצפה לקבל מספר לקוח כ-integer ושירות אחר מצפה לקבל מספר לקוח כ-string. יש לוודא שכל התקשורת בין השירותים עובדת כראוי.
צרכים מיוחדים בבדיקות SOA.
ממשק משתמש.
בדיקות התוכנה המסורתיות מניחות את קיומו של ממשק משתמש כלשהו, לעיתים גרפי, באמצעותו ניתן לתקשר עם המערכת על-מנת לבצע בדיקות פונקציונליות, בדיקות עומסים ועוד. בבדיקות SOA הממשק הנתון אינו גרפי ומגיע בפלטפורמות שונות (SOAP לדוגמה). על בודק התהליך לדעת להתממשק ולתקשר עם השירות הנבדק ואף לחבר אליו כלי בדיקה במידת הצורך.
העדר הממשק המסורתי מציג קושי נוסף - תרחישי שימוש מרובים וקלטים מהמשתמש. הממשקים המסורתיים "מגבילים" את המשתמש בכך שהם מנחים סדר פעולות ותרחישים קבועים ושדות קלט המנסים להגדיר את סוגי הקלט השונים. בהיעדר ממשק לבדיקת השירות, על הבודק לזהות תרחישים וקלטים אפשריים שכמותם עשויה להיות גדולה עד בלתי אפשרית לחיזוי. העדר "ראש" לשירות הנבדק מציג רמת קושי איתה נאלץ להתמודד הבודק.
פערים טכנולוגיים.
בפיתוח "מסורתי" רוב הפרויקט מתבצע כתהליך יחיד על ידי צוות אחד או יותר בתוך אותה החברה.
שירותי SOA מאוחסנים בשרתים מרוחקים, בסביבות טכנולוגיות הטרוגניות ופותחו על ידי מפתחים שונים בזמנים שונים. על בודק התוכנה להיות מסוגל לאסוף את כל השירותים המעורבים בתהליך יחד על-מנת ליצור בדיקה לתהליך שלם.
לוגיקה.
בשירותי SOA הלוגיקה של האפליקציה נמצאת במעיין שכבת ביניים, עושה שימוש במספר טכנולוגיות ונמצאת על-גבי שרתים מחוץ לארגון.
עובדה זו מציגה אתגר בפני הבודק שנאלץ לאתר בעיה או תקלה באפליקציה שהוא אינו יכול לצפות בלוגיקה שלה ולעיתים אף לא מציעה תמיכה מספקת.
QoS - איכות השירות.
באפליקציות "קלאסיות", העושות שימוש ברשת, העומס בו יעשו שימוש הלקוחות חזוי מראש. כמו כן, ידועים גם פרופילי המשתמש ותרחישי השימוש.
באפליקציה העושה שימוש בשירותי SOA, בשל השימוש בשירותים ואפליקציות חיצוניות, על המפתח לנסות ולחזות את כל תרחישי ופרופילי השימוש איתם תתמודד האפליקציה.
על הבודק, כחולייה בשרשרת קביעת איכות התוכנה, לקבוע האם האפליקציה עומדת בסטנדרט איכות השירות לה התחייבה החברה אל מול הלקוח, עם דגש על מגוון סוגי השימוש ועומסים נתונים, על-מנת לספק את שביעות רצונו.
אתגרים מיוחדים לבדיקות SOA.
בנוסף לצרכים המיוחדים הנובעים מההבדלים בין בדיקות "רגילות" לבדיקות SOA, קיימים אתגרים ייחודיים לבדיקות מכוונות שירותים המציבים אתגרים בפני הבודקים.
איך לבדוק ארכיטקטורה מכוונת שירותים (SOA).
כיצד לבדוק תוכנה בארכיטקטורת SOA? התשובה היא לא לבדוק.
יש לחשוב על תוכנה בארכיטקטורת SOA כלגו הבנוי מחלקים רבים. צריך לפרק את התוכנה לרכיבים הבנויים משירותים, בטיחות, מדיניות וכדומה ולבדוק כל רכיב בנפרד.
מדיניות - לארגון המייצר תוכנה בארכיטקטורת מכוונת שירותים חייבת להיות מדיניות מוגדרת היטב של בדיקות וסטנדרטים.
המדיניות צריכה לקבוע את הסטנדרטים בתחומים הבאים:
על צוות הבדיקות והמתכננים ליצור מקרי בדיקה לכל מדיניות כזו ולאכוף את יישום המדיניות לאורך כל תהליך הפיתוח.
בדיקות יחידה - בדיקת יחידה היא בדיקה של הרכיבים הכי קטנים שמרכיבים את התוכנה. כל שירות מורכב ממספר קומפוננטות.
בדרך כלל בדיקות אלו מבוצעות על ידי צוות המפתחים ומטרתם לבדוק שהפונקציונליות הבסיסית של הקומפוננטות בתוך השירות עובדת כראוי ובהתאם לתכנון. כל קומפוננטה תיבדק בנפרד לפני שתשלח לאינטגרציה לתוך שירות.
צריך לבדוק שהקומפוננטה עומדת במדיניות שהגדירה החברה.
בדיקות השירותים - בגלל העקרון של ארכיטקטורה מכוונת שירותים שיש למקסם את השימוש החוזר בשירות, נדרש מהשירות להיות נטול באגים ככל האפשר. באר שימצא בשירות יחלחל לכל הלקוחות שמשתמשים בו. מסיבה זו בדיקות שירותים הם החלק המרכזי בבדיקות ארכיטקטורת SOA.
הבדיקות הבאות נדרשות בעת בדיקת השירות:
בדיקות אינטגרציה - בדיקות אינטגרציה הם הבדיקות שבודקות את החיבור של כל השירותים השונים המרכיבים את התוכנה. כל מה שנוגע לאינטגרציה בתוכנה מועצם כאשר מדובר על ארכיטקטורת SOA. בבדיקות אינטגרציה של SOA צריכים לקחת בחשבון שירותים של צד שלישי, שירותים שנפלו או חסרים, שירותים שעברו שינוי ודברים נוספים שאינם קיימים בארכיטקטורה "רגילה".
השירותים מבוזרים ויכולים לרוץ על פלטפורמות שונות ולהיכתב בשפות שונות. המוסכמה ב-SOA שגם אם שירות משתדרג ומשתנה הוא חייב לתמוך בממשק אותו הוא פרסם ועל זה מתבססות גם הבדיקות. יש צורך לבדוק גם בתהליך הפיתוח וגם לאורך חיי המוצר שכל השירותים תומכים בממשק שהם פרסמו.
כיוון שהתוכנה מורכבת משירותים שונים יש לוודא שכל השירותים מתקשרים בצורה נכונה אחד עם השני. בבדיקות אלו יינתן דגש על בדיקות הממשקים של השירות ומעבר המידע בין השירותים. יבדקו פרוטוקולי הרשת והאבטחה הנדרשים לתקשורת בין השירותים.
בדיקות מערכת - בבדיקות אלו נבדוק את מוצר התוכנה השלם.
בדיקות אלו מתבצעות לאחר כל שלבי הבדיקות הקודמים ולכן נניח שכל שאר המרכיבים השונים בתוכנה כבר נבדקו. בבדיקות אלו נשים דגש בתרחישי השימוש השונים של המשתמשים. יבדקו התקינות של הטרנזקציות העסקיות שהלקוחות הגדירו בעת תכנון התוכנה. כדי להבטיח ששלב זה יבוצע כראוי יש לשלב בצוות בדיקות התוכנה גם את נציגי הלקוח.
בדיקות לא פונקציונליות -
כאשר השירות מפורסם ברשת לא ניתן לחזות במדויק מה תהיה רמת העומס בו הוא יצטרך לעמוד. שירותים יכולים להיות פופולריים במהרה וידרשו לתמוך במספר משתמשים רב בו זמנית.
צריכים להיכתב בדיקות שיבדקו כיצד השירות מתנהג שמביאים אותו לקצה היכולת מבחינת עומסי השימוש.