Blink
ग्रेग साइमन और एरिक सीडल की
Blink, Chrome का ओपन-सोर्स रेंडरिंग इंजन है. Blink की टीम, वेब को बेहतर बना रही है और डेवलपर को आने वाली समस्याओं को हल कर रही है.
अप्रैल में लॉन्च होने के बाद से, हमने इस सुविधा में कई सुधार किए हैं.
सबसे पहले, हमने अपने आधे सोर्स को मिटा दिया, जिसकी हमें ज़रूरत नहीं थी. हमारा काम अब भी पूरा नहीं हुआ है! हम ऐसा बिना सोचे-समझे नहीं कर रहे हैं: कोड हटाने का फ़ैसला, रिपोर्टिंग के लिए ऑप्ट-इन करने वाले Chrome उपयोगकर्ताओं से मिले आंकड़ों के आधार पर लिया जाता है. इन आंकड़ों में, उपयोगकर्ता की पहचान ज़ाहिर नहीं की जाती.
हम हर छह हफ़्ते में एक नया डेवलपर एपीआई पब्लिश करते हैं. यह Chrome के शिपिंग शेड्यूल के मुताबिक होता है.
Blink से फ़ोक करने के बाद, हमने एक बड़ा बदलाव किया था. हमने इंटेंट सिस्टम जोड़ा था: वेब प्लैटफ़ॉर्म में बदलाव करने से पहले, हम Blink डेवलपर को सार्वजनिक तौर पर सूचना भेजते हैं. इसमें, हम किसी सुविधा को जोड़ने या हटाने के बारे में बताते हैं. इसके बाद, हम इसे कोड में बदल देते हैं! सुविधा को चेक इन करने के अगले दिन ही, वह हमारे Canary बिल्ड में शामिल हो जाती है. यह सुविधा डिफ़ॉल्ट रूप से बंद रहती है. हालांकि, about:flags का इस्तेमाल करके इसे चालू किया जा सकता है.
इसके बाद, हम अपनी सार्वजनिक मेलिंग सूची पर, प्रॉडक्ट शिप करने के अपने इंटेंट की जानकारी देते हैं.
chromestatus.com पर जाकर, उन सुविधाओं के बारे में देखा जा सकता है जिन पर हमने काम किया है, जो सुविधाएं हमने लॉन्च की हैं, और जिन्हें हम बंद करने वाले हैं. Chromium रिलीज़ ब्लॉग भी देखा जा सकता है. इसमें गड़बड़ियों और हमारे ट्रैकर डैशबोर्ड के लिंक मौजूद हैं.
एक और बड़ा बदलाव यह है कि हम WebKit प्रीफ़िक्स हटा रहे हैं. इसका मकसद, Blink प्रीफ़िक्स का इस्तेमाल करना नहीं है, बल्कि रन-टाइम फ़्लैग (सिर्फ़ कंपाइल-टाइम फ़्लैग नहीं) का इस्तेमाल करना है.
Android वेबव्यू एक बड़ी चुनौती है – लेकिन HTML5Test से पता चलता है कि चीज़ें बेहतर हो रही हैं. हम वेब प्लैटफ़ॉर्म के एपीआई का एक सेट हर जगह उपलब्ध कराने के मामले में, डेस्कटॉप के बहुत करीब हैं. वेब ऑडियो इसका एक बेहतरीन उदाहरण है!
लेकिन सॉसेज बनाने वाली मशीन कैसे काम करती है? Blink में किए गए हर बदलाव को तुरंत 30,000 से ज़्यादा टेस्ट के ज़रिए चलाया जाता है. इसके अलावा, बाद में Chromium के सभी टेस्ट भी चलाए जाते हैं. हम 24 घंटे शेरिफ़िंग का इस्तेमाल करते हैं. इसमें हज़ारों बॉट, हज़ारों मानदंड, और ऐसे सिस्टम शामिल होते हैं जो हमारे इंजन पर लाखों ब्रोकन वेब पेज भेजते हैं. इससे यह पक्का किया जाता है कि इंजन काम करता रहे. हम जानते हैं कि मोबाइल पर यह सुविधा काफ़ी धीमी है. हम इसे बेहतर बनाने के लिए लगातार काम कर रहे हैं.
तो नया क्या है?
- वेब कॉम्पोनेंट: एरिक बिडलमैन का टॉक देखें!
- वेब ऐनिमेशन: जटिल, सिंक किए गए, बेहतर परफ़ॉर्मेंस वाले ऐनिमेशन, जो जहां भी हो सके वहां जीपीयू का इस्तेमाल करते हैं
- कुछ हिस्से का लेआउट: सिर्फ़ वही कैलकुलेट करें जो आपके काम का है!
- सीएसएस ग्रिड
- रिस्पॉन्सिव इमेज:
srcset या srcN या ? - टेक्स्ट का अपने-आप आकार बदलने की सुविधा तेज़ी से लागू होना और सब-पिक्सल फ़ॉन्ट का एक जैसा होना
- Blink का इस्तेमाल करने वाला ग्राफ़िक सिस्टम, Skia, Windows पर GDI से DirectWrite पर स्विच कर रहा है
हमें आपकी राय जाननी है!
अगर आपको C++ पसंद है और आपको हमारे साथ C++ कोड लिखना है, तो हमारे सभी कोड को ऐक्सेस किया जा सकता है. आपको किसी को बताने या हमें प्रमोशन करने की ज़रूरत नहीं है. इसके लिए, पैच पोस्ट करें या गड़बड़ी की शिकायत करें!
स्लाइड: पलक झपकाना
सुरक्षा
Parisa Tabriz की ओर से
आज के समय में, पहले के मुकाबले ज़्यादा लोग वेब से जुड़े हैं. साथ ही, वे अलग-अलग जगहों से वेब का इस्तेमाल कर रहे हैं.
हम अपने लैपटॉप, फ़ोन, और टैबलेट से कनेक्ट हैं. जल्द ही, हम निजी डिवाइसों और ऐक्सेसरी से भी कनेक्ट हो जाएंगे. हम इंटरनेट को अविश्वसनीय और कभी-कभी खतरनाक नेटवर्क से ऐक्सेस करते हैं. आजकल ज़्यादातर काम ऑनलाइन किए जा रहे हैं. इसलिए, यह ज़रूरी है कि हम अपने और अपने उपयोगकर्ताओं के डेटा को सुरक्षित रखने के लिए कदम उठाएं.
सबसे ज़रूरी बात यह है कि डेवलपर के तौर पर, हमें एसएसएल की ज़रूरत और काम करने के तरीके को समझना होगा.
एसएसएल क्या है? इसका मतलब है सिक्योर सॉकेट लेयर. यह एक क्रिप्टोग्राफ़िक प्रोटोकॉल है, जिसे इंटरनेट पर सुरक्षित तरीके से डेटा ट्रांसफ़र करने के लिए डिज़ाइन किया गया है. यह एन्क्रिप्शन और इंटिग्रिटी की मदद से, निजता की गारंटी देता है. इससे आपके इंटरनेट कनेक्शन को निगरानी करने या उसमें छेड़छाड़ करने से रोका जा सकता है. एसएसएल में कुछ गड़बड़ियां हैं, लेकिन इंटरनेट पर डेटा कम्यूनिकेशन की सुरक्षा को पक्का करने का यह सबसे अच्छा तरीका है. असल में, यह एकमात्र तरीका है.
SSL Pulse के मुताबिक, एक साल पहले हमारे पास 15% से कम एसएसएल था. अब हमारे पास 50% से ज़्यादा एसएसएल है.
दो छोटे शब्द:
टीएलएस: ज़्यादातर मामलों में, यह एसएसएल जैसा ही होता है. सटीक तौर पर, एसएसएल 3.1 का नाम बदलकर TLS कर दिया गया था. TLS, आईईटीएफ़ स्टैंडर्ड का नाम है. हालांकि, इन्हें एक-दूसरे की जगह इस्तेमाल किया जा सकता है!
एचटीटीपीएस: यह एसएसएल के ऊपर एचटीटीपी है. यह एसएसएल और स्टैंडर्ड एचटीटीपी की सुरक्षा सुविधाओं की लेयरिंग है. सबसे पहले, क्लाइंट–सर्वर हैंडशेक, सार्वजनिक/निजी पासकोड क्रिप्टोग्राफ़ी का इस्तेमाल करके शेयर की गई कुंजी बनाता है. इसका इस्तेमाल, एसएसएल प्रोटोकॉल के दूसरे हिस्से में, डेटा को एन्क्रिप्ट करने के लिए किया जाता है.
इंटरनेट पर नेटवर्किंग करना सुरक्षित, तुरंत, और तेज़ लग सकता है. ऐसा लगता है कि हम सीधे वेबसाइट से बात कर रहे हैं. हालांकि, असल में यह सीधा कनेक्शन नहीं है. आपके डिवाइस और वेबसाइट के बीच हमारा कम्यूनिकेशन, वाई-फ़ाई राऊटर, आईएसपी, और संभावित रूप से अन्य इंटरमीडियरी प्रॉक्सी के ज़रिए होता है. एचटीटीपीएस के बिना, हमारा सारा कम्यूनिकेशन सादे टेक्स्ट में होता है.
समस्या यह है कि उपयोगकर्ता शायद ही एचटीटीपीएस वाला पूरा यूआरएल टाइप करते हैं. इसके अलावा, वे एचटीटीपी का इस्तेमाल करके लिंक पर क्लिक करते हैं. इससे भी बुरा यह हो सकता है कि मैन-इन-द-मिडल हमला किया जाए और एचटीटीपीएस को एचटीटीपी से बदल दिया जाए. SSLstrip नाम का एक टूल, 2009 में लॉन्च किया गया था. यह टूल ठीक यही काम करता है. Firesheep, 2010 से खुले वाई-फ़ाई नेटवर्क पर भेजी जा रही कुकी को सुनता था: इसका मतलब है कि आपके पास चैट को सुनने या किसी के Facebook खाते में लॉग इन करने का विकल्प था.
हालांकि, एसएसएल (अपेक्षाकृत) सस्ता, तेज़, और आसानी से डिप्लॉय किया जा सकता है. ssllabs.com और इल्या ग्रिगोरिक की किताब 'हाई परफ़ॉर्मेंस ब्राउज़र नेटवर्किंग' देखें. पब्लिक पासकोड पिन करने की सुविधा को इस तरह से डिज़ाइन किया गया है कि वेबसाइट ऑपरेटर यह तय कर सकें कि उनकी साइटों के लिए सर्टिफ़िकेट देने वाली कौनसी सर्टिफ़िकेट अथॉरिटी सर्टिफ़िकेट जारी कर सकती है.
"इस साल (2010) जनवरी में, Gmail ने डिफ़ॉल्ट रूप से सभी चीज़ों के लिए एचटीटीपीएस का इस्तेमाल करना शुरू किया. इसके लिए, हमें कोई अतिरिक्त मशीन या खास हार्डवेयर डिवाइस डिप्लॉय नहीं करना पड़ा. हमारी प्रोडक्शन फ़्रंटएंड मशीनों पर, एसएसएल का इस्तेमाल करने पर सीपीयू लोड में 1% से कम, हर कनेक्शन में 10 केबी से कम मेमोरी, और नेटवर्क ओवरहेड में 2% से कम की कमी आती है…
अगर आपको अब पढ़ना बंद करना है, तो आपको सिर्फ़ एक बात याद रखनी होगी: एसएसएल का इस्तेमाल करने पर, अब प्रोसेसिंग में ज़्यादा समय नहीं लगता.”
– ओवरक्लॉकिंग एसएसएल, ऐडम लैंगले (Google)
आखिर में, कुछ ऐसी गड़बड़ियां जिनका हम अक्सर सामना करते हैं:
- मिले-जुले कॉन्टेंट वाली साइटें: ऐसी साइटें जो एचटीटीपी और एचटीटीपीएस, दोनों का इस्तेमाल करती हैं. कॉन्टेंट लोड करने के लिए, उपयोगकर्ता को अनुमति वाले बटन पर क्लिक करना पड़ता है. इससे, उपयोगकर्ता परेशान हो सकता है. (Chrome और Firefox, iframes से मिले-जुले कॉन्टेंट को रोकते हैं.) पक्का करें कि एचटीटीपीएस पेज पर मौजूद आपके सभी संसाधन, एचटीटीपीएस से लोड किए जाएं. इसके लिए, रिलेटिव या स्कीम-रिलेटिव यूआरएल का इस्तेमाल करें. उदाहरण के लिए,
<style src="//foo.com/style.css"> - असुरक्षित कुकी: इन्हें एचटीटीपी कनेक्शन के ज़रिए साफ़ तौर पर भेजा जाता है. कुकी हेडर पर secure एट्रिब्यूट सेट करके, इस समस्या से बचें. एसएसएल ट्रांसपोर्ट सिक्योरिटी (एचएसटीएस) की ज़रूरत पड़ने पर, नए "स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी" हेडर का भी इस्तेमाल किया जा सकता है.
सीखने वाली अहम बातें
- अगर आपको अपने उपयोगकर्ताओं के डेटा की निजता और सुरक्षा को लेकर ज़रूरत से ज़्यादा ध्यान रखना है, तो आपको एसएसएल का इस्तेमाल करना होगा. यह पहले से ज़्यादा तेज़, आसान, और सस्ता है.
- लागू करने से जुड़ी सामान्य समस्याओं से बचें. जैसे, अलग-अलग तरह के कॉन्टेंट से जुड़ी गड़बड़ियां या सही एचटीटीपी हेडर बिट सेट न करना.
- रिलेटिव या स्कीम रिलेटिव यूआरएल का इस्तेमाल करें.
- एचएसटीएस और सर्टिफ़िकेट पिनिंग जैसी कुछ नई सुविधाओं के बारे में जानें
स्लाइड: क्या आपके पास एसएसएल है?
एक से ज़्यादा डिवाइसों पर काम करने वाले वेब के लिए मीडिया एपीआई
सैम डटन और जान लिंडन की
वेब पर नए डिवाइसों और प्लैटफ़ॉर्म के साथ-साथ, ऑडियो, वीडियो, और रीयल-टाइम कम्यूनिकेशन में भी काफ़ी बढ़ोतरी देखने को मिल रही है. ऑनलाइन मीडिया ने, अलग-अलग तरह के मीडिया को इस्तेमाल करने के हमारे तरीके को बदल दिया है.
यूनाइटेड किंगडम की सरकार के एक अध्ययन में पता चला है कि 53% वयस्क टीवी देखते समय 'मीडिया मल्टी-टास्क' करते हैं. इसका मतलब है कि वे मीडिया शेयर करने और देखने के लिए, मोबाइल डिवाइसों का इस्तेमाल करते हैं. कई देशों में टीवी पर वीडियो देखने की संख्या में कमी आई है और ऑनलाइन वीडियो देखने की संख्या में बढ़ोतरी हुई है. उदाहरण के लिए, 2012 में बीजिंग में सिर्फ़ 30% परिवारों ने टीवी देखा, जो 2009 में 70% से कम था. W3C की हाइलाइट 2013 के मुताबिक, 'पिछले साल मोबाइल डिवाइसों पर वीडियो देखने की संख्या दोगुनी हो गई है. इस साल अमेरिका में, हर दिन डिजिटल मीडिया पर बिताया जाने वाला औसत समय, टीवी देखने के औसत समय से ज़्यादा हो जाएगा. अब टीवी देखने का तरीका बदल गया है. अमेरिका में, 87% मनोरंजन के उपभोक्ता कहते हैं कि वे टीवी देखते समय कम से कम एक सेकंड स्क्रीन वाले डिवाइस का इस्तेमाल करते हैं.' Cisco के मुताबिक, 'वीडियो ... साल 2017 तक दुनिया भर में उपभोक्ता ट्रैफ़िक का 80 से 90 प्रतिशत होगा'. इसका मतलब है कि हर सेकंड करीब एक लाख मिनट का वीडियो अपलोड किया जाता है.
तो वेब डेवलपर के लिए हमारे पास क्या है? ओपन वेब के लिए मीडिया एपीआई का नेटवर्क: स्टैंडर्ड और इंटरऑपरेबल टेक्नोलॉजी, जो कई प्लैटफ़ॉर्म पर काम करती हैं.
सीखने वाली अहम बातें
- WebRTC, ब्राउज़र में रीयल-टाइम कम्यूनिकेशन की सुविधा देता है. यह सुविधा अब मोबाइल और डेस्कटॉप पर भी काम करती है. फ़िलहाल, कुल 1.2 अरब से ज़्यादा WebRTC एंडपॉइंट मौजूद हैं.
- Web Audio, ऑडियो सिंथेसिस और प्रोसेसिंग के लिए बेहतरीन टूल उपलब्ध कराता है.
- वेब ऑडियो के साथ इंटिग्रेट किया गया वेब एमआईडीआई, एमआईडीआई डिवाइसों के साथ इंटरैक्ट करने की सुविधा देता है.
- ऑडियो और वीडियो एलिमेंट अब 85% से ज़्यादा मोबाइल और डेस्कटॉप ब्राउज़र पर काम करते हैं.
- मीडिया सोर्स एक्सटेंशन का इस्तेमाल, अडैप्टिव स्ट्रीमिंग और टाइम शिफ़्ट करने के लिए किया जा सकता है.
- EME, सुरक्षित कॉन्टेंट चलाने की सुविधा देता है.
- ट्रांसक्रिप्ट, कैप्शन, और ट्रैक एलिमेंट की मदद से, सबटाइटल, कैप्शन, समय के हिसाब से मेटाडेटा, डीप लिंकिंग, और डीप सर्च की सुविधा चालू की जा सकती है.