माइकल Mahemoff: "आप पढ़ या सुनकर अध्ययन नहीं कर सकते"

माइकल Mahemoff - ऑस्ट्रेलियाई, मेलबोर्न विश्वविद्यालय से स्नातक की उपाधि प्राप्त, अब Google के लंदन कार्यालय में काम करता है। माइक के अनुसार, उनके दूर के पूर्वज रूस और पोलैंड से थे, लेकिन उनके माता-पिता पहले से ही ऑस्ट्रेलिया में पैदा हुए थे। हाल ही में GDD में, माइकल ने एक विशद छाप छोड़ी। करिश्माई और भावुक, वह Google टीम के पारंपरिक रूप से मजबूत वक्ताओं की पृष्ठभूमि के खिलाफ भी खड़ा था। यह हैकथॉन में विशेष रूप से ध्यान देने योग्य था, जहां वह दर्जन भर गुग्लरों के सबसे अधिक इच्छुक और सक्रिय सदस्य थे। यह मुझे लगता है कि माइकल Mahemoff Google inc की नई पीढ़ी के उभरते सितारों में से एक है।

GDDru के बाद चेक ब्लॉगर मार्टिन हसमैन द्वारा दर्ज किया गया साक्षात्कार

कीव GTUG केंद्र के सबसे बड़े समन्वयक (यूक्रेनी अनुवाद में मदद के लिए, धन्यवाद @MsCentaurea )



माइकल Mahemoff Google पर क्रोम डेवलपर एडवोकेट के रूप में काम करता है। वे कई वर्षों से अजाक्सियन के लिए लिख रहे हैं, और 2006 में अजाक्स डिज़ाइन पैटर्न पुस्तक भी लिखी है, जिसे ओ'रिली द्वारा प्रकाशित किया गया था। वह ListOfTweets.com , साथ ही साथ मजेदार प्रोजेक्ट IE6IsOlderThanYourGrandpa.com जैसे उपयोगी टूल के लेखक हैं। वह Softwareas.com पर ब्लॉग करता है और @ mahemoff नाम से ट्विटर पर सक्रिय है।





JSConf2010 में माइकल Mahemov

आप पांच साल से अजाक्सियन के लिए लिख रहे हैं, अर्थात्। आप इस क्षेत्र में विकास का बारीकी से अनुसरण कर रहे हैं। क्या, आपकी राय में, पिछले पांच वर्षों में जावास्क्रिप्ट और AJAX में सबसे महत्वपूर्ण परिवर्तन हुए हैं?

जावास्क्रिप्ट की हमारी समझ में, जैसे कि धीरे-धीरे सुधार किया गया है, कई बदलाव हुए हैं, उदाहरण के लिए, jQuery और Firebug जैसे पुस्तकालयों और उपकरण दिखाई दिए हैं, जिन्होंने डेवलपर्स के जीवन को बहुत सरल किया है। एक और फायदा था उत्पादकता में उल्लेखनीय वृद्धि। लेकिन, मेरी राय में, अजाक्स के बाद मोड़, हाल ही में नई ब्राउज़र क्षमताओं का उदय था। उन्हें HTML5, CSS3 और अन्य संबंधित तकनीकों के लिए लागू किया जाता है, जैसे कि, उदाहरण के लिए, जियोलोकेशन सेवाएं (हम इन सभी तकनीकों को "HTML5 सुविधा के लिए" कह सकते हैं)। आखिरकार, इससे पहले, कोई फर्क नहीं पड़ता कि आप जावास्क्रिप्ट के साथ काम करने में सक्षम थे, उन्होंने आपको वीडियो और समृद्ध ग्राफिक्स बनाने का अवसर नहीं दिया। उन गुणों को प्राप्त करने के लिए जिन्हें आधुनिक अनुप्रयोगों की आवश्यकता होती है, हमें प्लग-इन, हैक और वर्क-अराउंड का उपयोग करना पड़ा। अब, HTML5 के लिए धन्यवाद, हम कई एप्लिकेशन प्रोग्रामिंग इंटरफेस / एपीआई बनाने में सक्षम हैं जो इन सुविधाओं का समर्थन करते हैं और खुले मानक हैं। पिछले तरीकों के विपरीत, वे खुले मानकों पर आधारित होते हैं और आमतौर पर तेज, सुरक्षित, अधिक शक्तिशाली होते हैं, और डेवलपर्स के लिए काम करना भी आसान होता है।





मॉस्को हैकाथॉन में माइकल और पॉल किनलान (11/11/2010, GDDru)



प्रोग्रामिंग के अलावा, आपने मनोविज्ञान का अध्ययन किया। इन विषयों में क्या समानता है?

बहुत कुछ। उदाहरण के लिए - कृत्रिम बुद्धि, जो हमेशा इन क्षेत्रों के चौराहे पर मौजूद है और अनुसंधान के लिए एक आकर्षक विषय बना हुआ है। लेकिन पिछले एक दशक में, उपयोगकर्ता की बातचीत में सुधार आया है, एक विशुद्ध रूप से अनुसंधान आला छोड़ दिया गया है और आधुनिक प्रोग्रामिंग का एक प्रमुख अनुशासन या उप-निरीक्षक बन गया है। अब हम लगातार उत्पादों की समीक्षाओं के साथ मिलते हैं, और उन कारकों में से एक है जो उपयोगकर्ता के लिए ऐसे उत्पादों की सुविधा है; लोगों को एक कार्यक्रम से एक सहज ज्ञान युक्त अंतरफलक की उम्मीद है। और आप मानव मनोविज्ञान की विशेषताओं को समझकर ही इस तरह का इंटरफ़ेस बना सकते हैं। मनोविज्ञान नंगे सिद्धांत पर काम नहीं करता है, बल्कि तथ्यों पर आधारित एक अनुशासन है।



आपने अजाक्स डिज़ाइन पैटर्न के बारे में एक किताब लिखी है। आपने प्रोग्रामिंग और ब्लॉगिंग से किताब लिखने तक कैसे कदम रखा?

पुस्तक का आधार उसी विषय पर मेरे ब्लॉग पोस्ट थे। मैंने विचार में आने के बाद देखा कि अजाक्स शब्द आखिरकार भाषा में तय किया गया था। लोग रुचि रखते थे, मेरे ब्लॉग में मैंने कई प्रासंगिक साइटों (स्वादिष्ट लोकप्रिय, आदि) के बारे में बात की, और ओ 'रेली प्रकाशक ने मुझे एक किताब लिखने के लिए कहा। मैं अपने ब्लॉग पर पुस्तक में शामिल सामग्रियों के अंश प्रकाशित करना जारी रखता हूं, यह पूरी तरह से विकी शैली में निर्धारित है। अगर मैं दूसरी किताब लिखता हूं, तो शायद मैं विकि शैली से बचने और ब्लॉग पर अधिक ध्यान केंद्रित करने की कोशिश करूंगा, या कम से कम विकी टिप्पणियों के साथ। मुझे ऐसा लगता है कि पाठकों से प्रतिक्रिया प्राप्त करने का यह सबसे अच्छा तरीका है, क्योंकि लोग शायद ही कभी लंबे लेखों को संपादित करते हैं जो ज्यादातर एक व्यक्ति द्वारा लिखे गए हैं और केवल अपनी राय व्यक्त करते हैं। (और अगर वे करते हैं, तो आधे मामलों में यह सिर्फ स्पैम है!)



आपने TiddlyWiki पर कुछ समय के लिए काम किया। यह एक अजीब परियोजना का एक सा है, है ना? आप उसके बारे में क्या पसंद करते हैं?

हां, मैंने ओस्मोसॉफ्ट में टिडलीविकी पर काम किया, जो ब्रिटिश टेलीकॉम (बीटी) का एक अभिनव समूह है, जिसका नेतृत्व टिडलीविकी के संस्थापक जेरेमी रुस्टन करते हैं। लेकिन वास्तव में, मैंने बहुत पहले कोड पर काम करना शुरू कर दिया था जब मैंने अजाक्स डिज़ाइन पैटर्न के लिए लेख लिखे थे। हां, यह बहुत विशिष्ट परियोजना है। मैं मजाक करता हूं कि मैं दुनिया के उन कुछ लोगों में से एक हूं, जिन्हें यूआरआई प्रारूप के साथ काम करने वाले इंटरनेट एप्लिकेशन बनाने के लिए भुगतान किया गया है। इसके मूल में, TiddlyWiki एक एकल फ़ाइल में HTML, CSS और जावास्क्रिप्ट के संयोजन द्वारा बनाया गया एक पृष्ठ का अनुप्रयोग है। यह पहले से ही एक नवीनता थी जब हमने पहली बार इस तरह की फाइल बनाई थी। लेकिन जो वास्तव में उसे अलग करता है, वह किसी भी ब्राउज़र एक्सटेंशन के बिना, और एचटीएमएल 5 के बिना ऑफ़लाइन एपीआई का उपयोग किए बिना डेटा को स्थानीय हार्ड ड्राइव में सहेजने की उसकी क्षमता है। यह Internet Explorer में ActiveX के उपयोग के लिए संभव है, फ़ायरफ़ॉक्स में मोज़िला की अपनी एपीआई, और अन्य ब्राउज़रों में अतिरिक्त अंतर्निहित फ़ाइल के लिए धन्यवाद। इसका मतलब है कि आप आसानी से एक साझा ड्राइव पर एक HTML फ़ाइल स्थापित करके मजबूत वेब अनुप्रयोग और यहां तक ​​कि "पक्षपातपूर्ण" बहु-उपयोगकर्ता अनुप्रयोग बना सकते हैं। एक और दिलचस्प विशेषता प्लगइन सिस्टम है। हालाँकि TiddlyWiki एक व्यक्तिगत विकी पृष्ठ की उपस्थिति को डिफॉल्ट करता है, आप इसे ब्लॉग, स्लाइड शो, या किसी अन्य चीज़ में बदल सकते हैं। मैंने एक डेमो दर्ज किया जिसमें दिखाया गया कि 15 मिनट में एक मंच कैसे बनाया जाए । इसके लिए TiddlyWeb का भी उपयोग किया गया था, इसलिए मंच पूरी तरह से सर्वर पर है, हालांकि यह URI फ़ाइल पर आधारित है।





माइकल कीव GTUG सेंटर हैकाथॉन में (कीव, 10.23.2010)



आपको हैकेथॉन बहुत पसंद है। आपको क्या लगता है उनकी ताकत क्या है?

हां, मुझे वास्तव में कुछ हैकथॉन पसंद हैं। प्रोग्रामिंग, एक अनुशासन के रूप में, दोनों की ताकत और कमजोरियां हैं। मुख्य ताकत यह है कि आप एक ही दिन में कुछ अद्भुत बना सकते हैं! या, भले ही अधिकांश लोग एक दिन में समाप्त होने वाली किसी चीज का निर्माण नहीं कर सकते, फिर भी वे कुछ करने में सफल होंगे और एक ही समय में, वे इस प्रक्रिया में बहुत कुछ सीखेंगे। इस प्रकार, हैकाथॉन किसी नई चीज़ के अद्भुत निर्माण की विजय है। आखिरकार, हम विचारों के एक दाने को बो कर दिन की शुरुआत कर सकते हैं, और शाम को पहले से ही इसके तत्काल अवतार को देख सकते हैं! यह प्रोग्रामिंग की प्रकृति है: सूचना और निर्माण का निरंतर प्रवाह। इस सब में एक सामाजिक पहलू भी है - नए परिचितों को एक टीम के रूप में काम करना, अनुभवों का आदान-प्रदान करना और एक दूसरे से कुछ सीखना। और ये लक्ष्य उतने ही प्राप्त किए जा सकते हैं जितने उपयोगकर्ता चाहते हैं: आखिरकार, कुछ व्यक्तिगत काम पसंद करते हैं और यह भी अद्भुत है। किसी भी मामले में, प्रोग्रामिंग की एक महत्वपूर्ण विशेषता यह है कि आप केवल पढ़ने या सुनने के द्वारा प्रोग्राम करना नहीं सीख सकते हैं। हम कारणों के बारे में बहस कर सकते हैं, लेकिन ज्यादातर डेवलपर्स मुझसे सहमत होंगे कि आप केवल अपनी आस्तीन को रोल करके और वास्तविक कोड बनाने पर काम करके सिद्धांतों को समझ सकते हैं। हैकथॉन ऐसे काम के लिए एक आदर्श वातावरण है, एक सुरक्षित आश्रय है, जहां परिणाम इतना महत्वपूर्ण नहीं है, लेकिन मदद और प्रतिक्रिया प्राप्त करने के कई अवसर हैं।



आपने किस हैकथॉन में भाग लिया, वह सबसे लंबा था?

बीटी में, हमने एक लचीला दृष्टिकोण का अभ्यास किया, तीन दिनों के लिए घटनापूर्ण थे। पूरे बिंदु परियोजना में रुचि रखने वाले सभी लोगों को एक साथ लाने और उपयोगकर्ताओं का ध्यान आकर्षित करने के लिए, उनके साथ काम करने के लिए और ताकि वे तुरंत हमारे नए विकास का परीक्षण करें। हम अपने विचारों पर चर्चा कर सकते हैं और उन्हें कार्यान्वयन के एक नए चरण में ला सकते हैं। सब कुछ कहाँ नहीं गया। मैंने महसूस किया कि कभी-कभी हमें शक्ति के सही संतुलन को प्राप्त करने के लिए अधिक डेवलपर्स की आवश्यकता होती है, इस तरह के आयोजन में वास्तविक उत्पादों को बनाने और हर दिन के अंत में इन उत्पादों को प्रस्तुत करने पर ध्यान केंद्रित किया जाता है। कुछ लोग इस बात से परेशान थे कि सॉफ्टवेयर को रोजाना काम करना चाहिए, और न केवल असाधारण मामलों में, बल्कि मेरा मानना ​​है कि बहु-स्तरीय बहुराष्ट्रीय निगम में इस तरह के "बड़े धमाके" सबसे अच्छे और प्रभावी तरीके हैं। मेरा मानना ​​है कि यह सही सिद्धांत है, और ऐसे आयोजन वास्तव में कंपनी के लिए उपयोगी होते हैं।



तो, क्या ओसमोसॉफ्ट ने कंपनी के अंदर हैकथॉन की मेजबानी की? कंपनियों को वास्तव में हैकथॉन क्यों रखना चाहिए?

हां, वे अविश्वसनीय रूप से प्रभावी हैं, और हमने उन्हें महीने में लगभग एक बार आयोजित किया, क्योंकि ओस्मोसॉफ्ट में कई आंतरिक ग्राहक और बाहरी भागीदार थे। महान यादें! हम सुबह ग्राहकों से मिले, आमतौर पर कुछ लोग आते थे। हम इस घटना के लिए एक परिदृश्य पर सहमत हुए, विचारों पर चर्चा की और प्राथमिकता दी और फिर हैकाथॉन और कोडिंग के लिए आगे बढ़े। प्रोग्रामिंग सत्र एक घंटे या दो बजे तक चला, जो सुबह 10 बजे शुरू हुआ, और शाम 7 बजे तक चला जब हमने अपने काम के परिणाम प्रस्तुत किए। सत्रों के बीच, हमने अपनी गतिविधियों के समन्वय और अगले सत्र की योजना बनाने के लिए विचार-विमर्श किया। आदर्श रूप से, हम लगातार GitHub या इसी तरह की सेवाओं में गए, और इस घटना के बारे में ट्वीट भी किया। अंतिम लक्ष्य न केवल हमारे काम के परिणामों को पेश करना था, बल्कि वेब एप्लिकेशन के लिए सार्वजनिक पहुंच प्रदान करने के लिए घटना के अंत तक भी था जिसे हमने विकसित किया था (हालांकि व्यवहार में यह हमेशा संभव नहीं था)।

दो महत्वपूर्ण बिंदुओं पर ध्यान दिया जाना चाहिए। सबसे पहले, हम बहुत तेज़ी से काम कर सकते हैं, इस प्रकार अक्सर हमारे ग्राहकों को आश्चर्यचकित करते हैं। इसका कारण यह है कि हमने पुन: उपयोग पर जोर दिया है - प्रत्येक नई परियोजना न केवल एक नया एप्लिकेशन बनाने का एक अवसर थी, बल्कि कई नए घटक भी थे जिनका उपयोग अन्य परियोजनाओं में किया जा सकता है। एक भव्य तकनीकी विकास नहीं है, लेकिन TiddlyWiki के रूप में इस तरह के 50-लाइन प्लगइन आज वास्तव में कुछ उपयोगी हो गए हैं। यह एक टिप्पणी प्लगइन, ग्राफिक संपादक या पाठ काउंटर हो सकता है। दूसरी बात, खुलापन अपने आप में अद्भुत था, जो कंपनी द्वारा नए उत्पाद बनाने की प्रक्रिया के साथ था। हम इसे बर्दाश्त कर सकते थे, क्योंकि हमने एक शेल बनाया था जो प्लगइन्स पर आधारित था। ओस्मोसॉफ्ट, एक ओपन सोर्स सॉफ्टवेयर कंपनी के रूप में, ओपन सोर्स कंपोनेंट्स के साथ-साथ ऐसे एप्लिकेशन भी बनाए जो अनिवार्य रूप से इन कंपोनेंट्स का एक संयोजन था। इस स्तर पर, बीटी विकास का उपयोग कर सकता है और उन्हें अपनी जरूरतों के अनुकूल बना सकता है, ठीक उसी तरह जैसे कोई भी अन्य कंपनी (जैसे हमारे बाहरी साझेदार) उनका उपयोग कर सकते हैं। बेशक, व्यवहार में, हम बीटी का केवल एक हिस्सा थे और अनुप्रयोगों को अनुकूलित और वितरित करने में प्रत्यक्ष सहायता प्रदान करते थे। लेकिन हमने दिखाया कि बड़ी कंपनियां भी ओपन सोर्स सॉफ्टवेयर के साथ काम कर सकती हैं, और हैकथॉन के फायदों का भी प्रदर्शन किया।





कीव 10/23/2010



आपने Chrome डेवलपर एडवोकेट के रूप में Google Inc. आपको यह पद कैसे मिला? क्या आप स्वयं Google के लिए काम करना चाहते थे या आपको कंपनी के कर्मचारियों द्वारा आमंत्रित किया गया था?

Google के किसी व्यक्ति ने मुझे इस पद के लिए प्रतियोगिता में भाग लेने के लिए आमंत्रित किया, और फिर मैं मानक चयन प्रक्रिया से गुज़रा।



Chome कई अन्य ब्राउज़रों की तरह एक्सटेंशन का समर्थन करता है। लेकिन प्रत्येक ब्राउज़र में वे अपने तरीके से लागू होते हैं। क्या यह इंटरफ़ेस को एकीकृत करने के लिए समझ में आता है ताकि डेवलपर्स को एक बार एक्सटेंशन लिखने और उन्हें प्रत्येक ब्राउज़र में अनुकूलित न करने का अवसर मिले?

जाहिर है, एक सकारात्मक समाधान एक बार एक्सटेंशन लिखना और कई ब्राउज़रों के लिए चलना होगा; जो सामान्य रूप से वेब प्रोग्रामिंग के लिए एक बहुत बड़ा धन होगा। नुकसान समय से पहले नवाचार प्रक्रिया के विकास को रोकने का जोखिम होगा। फ़ायरफ़ॉक्स के लिए विस्तार तंत्र ने फायरबग जैसी अद्भुत चीजों को बनाना संभव बना दिया, लेकिन साथ ही यह वेब डेवलपर्स के दैनिक कार्य के लिए मुश्किल था और इसमें सुधार की आवश्यकता थी, फिर भी कुछ चीजों को मानकीकृत करना बहुत जल्दबाजी थी। मुझे उम्मीद है कि अब जब क्रोम में वेब डेवलपर्स के लिए शेल एक्सटेंशन सुविधाजनक है, तो मोज़िला जेटपैक है, और सफारी और ओपेरा में कुछ विस्तार तंत्र भी हैं, लोग वेन आरेख तैयार करना शुरू कर देंगे और सभी ब्राउज़रों के साथ काम करने के लिए एक सामान्य आधार खोजने की कोशिश करेंगे। लेकिन केवल अगर यह ब्राउज़रों को नवाचार और विकास का समर्थन करने से नहीं रोकता है। Chrome ने हाल ही में एक्सटेंशन पेश किए हैं जो आपको संदर्भ मेनू में एक्सटेंशन कमांड जोड़ने की अनुमति देते हैं; यह निरंतर सुधार का एक उदाहरण है जिसे मानकीकरण प्रक्रिया द्वारा रोका नहीं जाना चाहिए।



एक वक्ता के रूप में इस वर्ष आप कितने GDD जाएंगे?

मैं तीन GDD पर एक वक्ता के रूप में कार्य करूँगा जो यूरोप में (म्यूनिख, मॉस्को और प्राग में) आयोजित किया जाएगा, प्रत्येक घटना में दो रिपोर्टों के साथ: Google Chrome और HTML या मोबाइल विकास के लिए मूल निवासी एक्सटेंशन। दूसरी रिपोर्ट मैं एंड्रॉइड वकील रेटो मेयर के साथ मिलकर करूंगा, इसलिए मुझे लगता है कि रिपोर्ट दिलचस्प होगी।



क्या आप कभी प्राग गए हैं या यह आपकी पहली यात्रा है? आपको सबसे ज्यादा क्या उम्मीद है?

मैं प्राग नहीं गया हूं, और मैं इस यात्रा के लिए उत्सुक हूं। मेरे लिए सबसे दिलचस्प घटना GTUG द्वारा आयोजित प्री-जीडीडी इवेंट होगी। निश्चित रूप से चेक गणराज्य में डेवलपर्स का एक मजबूत समुदाय है, इसलिए मैं स्थानीय डेवलपर्स के साथ बैठक करने के लिए उत्सुक हूं और देखना चाहता हूं कि वे मुझे कैसे आश्चर्यचकित करेंगे।



मार्टिन हैमन ने प्राग की अपनी यात्रा से पहले माइकल Mahemoff का साक्षात्कार लिया



मास्को और कीव हैकथॉन से तस्वीरें।