1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Microsoft ile IBM'in OS/2'yi birlikte geliştirdiği dönemde, iletişim kutularında alanlar arasında geçiş için hangi tuşun kullanılacağı, organizasyon yapısı farkını ortaya koyan bir tartışma konusu oldu
  • Boca Raton'daki IBM ofisine gönderilen bir Microsoft çalışanı, alan geçiş tuşu olarak TAB tuşunun kullanılmasına karar verdi ve IBM bu konunun Redmond'daki yöneticiye iletilmesini istedi
  • Microsoft yöneticisi, onun Boca'da bulunma sebebinin tam da bu tür kararları kendi yerine vermesi olduğunu söyledi; bu mesaj IBM'e “Microsoft bu amaçla TAB tuşunun kullanılmasını destekliyor” şeklinde aktarıldı
  • IBM bununla yetinmedi ve kurumsal hiyerarşi boyunca konuyu birkaç kademe yukarı taşıdı; programcıdan yaklaşık 7 seviye yukarıdaki bir başkan yardımcısının (VP) buna karşı olduğunu söyleyerek Microsoft'ta da dengi bir yöneticinin onayını istedi
  • Microsoft çalışanı, “Bill Gates'in annesi TAB tuşuyla ilgilenmiyor” diye yanıt verdi; ardından tartışma fiilen sona ermiş görünüyor ve TAB tuşu yerinde kaldı

OS/2 iş birliğinde ortaya çıkan organizasyon yapısı farkı

  • Microsoft ile IBM'in OS/2'yi birlikte geliştirdiği dönemde kültürel çatışmalar yaşanıyordu; Microsoft tarafı IBM'li meslektaşlarının gereksiz bürokrasiye bağlı olduğunu düşünürken, IBM tarafı Microsoft çalışanlarını disiplinsiz hacker'lar olarak görüyordu
  • Çatışma noktalarından biri organizasyon yapısıydı ve bir iletişim kutusunda (dialog box) bir alandan diğerine geçerken hangi tuşun kullanılacağı tartışma konusu oldu
  • Bir Microsoft çalışanı, Florida'daki Boca Raton IBM ofisine atanmıştı ve alan geçiş tuşu olarak TAB tuşunu kullanmaya karar verdi
  • IBM tarafı bu karardan memnun kalmadı ve konunun Redmond'daki yöneticisine taşınmasını talep etti

Microsoft'un yetki devri ve IBM'in yukarı taşıma süreci

  • Microsoft yöneticisi, “Boca'da olma sebebin, benim Boca'da bulunmama gerek kalmadan bu tür kararları verebilmen” diye yanıt verdi
  • Bu yanıt IBM'e iletilmeden önce daha kurumsal bir dile çevrilerek “Microsoft bu amaçla TAB tuşunun kullanılmasını destekliyor” halini aldı
  • IBM tarafı bununla da yetinmedi ve organizasyon şeması boyunca meseleyi birkaç kademe yukarı taşıdı
  • IBM, programcıdan yaklaşık 7 seviye yukarıda bulunan bir VP'nin bu amaçla TAB kullanılmasına kesinlikle karşı olduğunu söyleyerek Microsoft tarafında da dengi bir yöneticinin onayını talep etti

Tartışmanın sonu

  • Microsoft çalışanı, “Bill Gates'in annesi TAB tuşuyla ilgilenmiyor” diye yanıt verdi
  • Bu yanıtın ardından tartışma sona ermiş görünüyor ve TAB tuşu kullanılmaya devam etti
  • Yazı, ABD'de yaklaşan pazar gününün Mother's Day olduğu ama annenize TAB tuşu hakkındaki görüşünü sormanın tavsiye edilmeyeceği esprisiyle bitiyor
  • Microsoft ile IBM'in birbirine dair değerlendirmelerinin ikisinin de bir ölçüde haklı olabileceği ima ediliyor

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları
  • IBM efsanevi derecede aşırı bürokratikti
    Eskiden birlikte çalıştığım biri, 90'ların ortasında Londra'daki IBM'de yaz stajyeri olarak bugün QA mühendisliği diyeceğimiz türden bir iş yapıyormuş; o sırada herkesin takım elbiseyle geldiği kültür değişmekte olduğundan, stajyerler sadece cuma günleri rahat kıyafet giyebilmek için izin istemiş.
    Müşteriyle hiç görüşmeyip arka odada kapalı çalıştıkları için bunun büyük bir mesele olmadığını düşünmüşler, ama yanıt ancak aylar sonra, stajın bitmesine çok az kala gelmiş; istek Londra ofisindeki dört onay kademesinden geçip ABD merkezine gitmiş, oradan da bir başkan yardımcısının masasına kadar çıkmış.
    Görünüşe göre her kademe, böyle önemli bir konuda karar verme yetkisi olup olmadığını düşünerek haftalar harcamış; yanıt da aynı yolu tek tek geri inip Atlantik'i geçerek Londra'daki takım elbiseli stajyerlere ulaşmış, ama o sırada stajın bitmesine sadece birkaç gün kalmış.
    Cevap hayır olmuştu.

    • 90'ların sonlarında başka bir ülkeye taşınıp iş ararken, OS/2 deneyimim olduğu için yerel IBM ofisine başvurmuştum; kısa süre sonra başka yerlerden 3 teklif aldım, birini kabul ettim ve IBM başvurusunu tamamen unuttum.
      Sonra 8 ay sonra IBM HR beni arayıp gelecek perşembe görüşmek isteyip istemediğimi sordu; artık ilgilenmediğimi söyleyince tamamen afalladılar.
      Ne düşündüklerini bilmiyorum ama, iyi maaş da vermeden inanılmaz derecede kendini beğenmiş davranıyorlardı.
    • Babam tüm kariyeri boyunca IBM'de çalıştı; siyah olmayan takım elbise giyilebileceği söylenince mavi takım elbise ile gitmiş, yöneticisi de ona “Otobüsle mi geldin?” diye sormuş.
    • 1988-89'da Birleşik Krallık Winchester'daki IBM Ar-Ge sahasında 1 yıllık staj yaptım; stajyerlerin hiçbirinin takım elbise ya da kravat taktığını hatırlamıyorum, kalıcı IBM çalışanlarının da çoğu öyle değildi.
      Oldukça gayriresmî bir ortamdı; yukarıdaki hikâyeyi yalanlamaya çalışmıyorum, sadece başka bir bakış açısı ekliyorum.
    • Mr. Show'un “Change for a Dollar” skeci: https://www.youtube.com/watch?v=KyocQT4Vn2g
    • Bunun gibi birkaç örnek var.
      İş dışında ürettiğim fikrî mülkiyet üzerinde IBM'in öncelik hakkı olmasına dair sözleşme maddesi için istisna istemiştim.
      Sonuçta sadece teknik destek çağrı merkezinde çalışıyordum; IBM'e ait özel bilgilere erişimim yoktu, geliştirme rolüm de yoktu, dolayısıyla bu açıdan sıfır risk vardı.
      Gerçekte yüz yüze görüşebildiğim herkes bunun son derece makul bir talep olduğunu düşünüyordu, ama ilk ret yanıtının gelmesi 6 hafta sürdü; doğrudan yöneticim araya girmeye çalışınca incelemeye 2 hafta daha eklendi, ama sonuç yine ret oldu.
      Talep raporlama zinciri boyunca ABD'ye kadar çıkıp hukuk tarafına sapmış, sonra geri inmiş gibi görünüyordu; sonunda bir arkadaşla küçük bir yazılım projesi yapsam bile IBM'in hak iddia etmesi riskinden kaçınmak için şirketten ayrıldım.
      Bir de HR formları 80'lerin başında hazırlanıp 2000'lerde dijitalleştirilmişti; müşteriyle yüz yüze olmayan bizim ekip ise son derece çeşitliydi.
      Formların farklı cinsiyet/zamir kombinasyonlarını tanıyacak şekilde güncellenmesine yönelik bir girişim olmuştu; inceleme yaklaşık 12 hafta sürdü ve sonunda sanırım kimse formu kimin değiştirmesi gerektiğini bulmak istemediği için reddedildi.
      Ekipte çok sayıda LGBT çalışan vardı ve onları elde tutmak önemli görünüyordu, ama buna rağmen çok net biçimde reddedildi.
      Cinsel tacizi önleme eğitimi 2010'da kaset üzerinden veriliyordu; üstünde de “güncellenmiş sürüm” yazdığına göre, önceki sürüm belki plak üzerindeydi.
  • Bu hikâye bana tuhaf geliyor çünkü IBM birçok ürününde klavye adlandırmasını tutarlı biçimde kullanıyordu ve 3270 ailesi ana bilgisayar terminallerinde, modern klavyedeki Tab konumunda bulunan Tab tuşu imleci bir sonraki alana taşımak için kullanılıyordu.
    https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... PDF sayfa 73
    Ayrıca IBM terminallerinde alanlar arasında gezinmek önemli olduğundan, Tab tuşunun karşı tarafında özel bir Back Tab tuşu da vardı.
    Orijinal IBM PC'de bu iki işlev tek tuşta birleştirildi; bu yüzden klasik PC klavyelerindeki Tab tuşunda hem ileri Tab hem geri Tab simgesi bulunur ve geri Tab simgesinin üstte olması Shift basılması gerektiğini gösterir.
    Ek olarak 5250 ailesi terminaller Tab/Back Tab yerine “Field Advance” ve “Field Backspace” terimlerini kullanıyordu, ama tuş sembolleri ve konumları 3270 ailesiyle kabaca aynıydı.
    Referans: https://www.bitsavers.org/pdf/ibm/5291/GA21-9409-0_5291_Disp...

    • Gerçek bir IBM 3270 klavyesi şöyle görünür[1].
      Soldaki “Next field” tuşuna ve sağdaki karşılığı “Previous field” tuşuna bakın.
      IBM 3270 bir form doldurma cihazıydı; mainframe boşluklar içeren bir formu terminale gönderir, kullanıcı da boşlukları doldururdu.
      Terminal donanımı formun sabit kısımlarının üzerine yazılmasını engeller, sayısal alanlar gibi kısıtları da uygular ve tüm bu işlemler terminalde yapılırdı.
      Form tamamlanınca kullanıcı ENTER'a basar ve doldurulmuş form tek bir işlem olarak mainframe'e gönderilirdi.
      Bu sayede tek bir mainframe çok büyük sayıda terminali kaldırabilir, kullanıcı da yazarken gecikme hissetmeden ve ekrana bakmadan hızlıca veri girebilirdi.
      PC tarafında böyle bir kullanım modeli yoktu; PC insanlarının aklındaki şey “daktilo”ydu.
      İlk ev bilgisayarı terminallerinden biri de “TV Typewriter” diye adlandırılmıştı.
      Web formları bu modele sahip, ama çok daha az tutarlı.
      [1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...
    • IBM'de çalışmış biri olarak tahminim şu: Tab tuşunun bu şekilde kullanımı, IBM'in üzerinde çalıştığı bir patentin parçasıydı ve Microsoft aynı şekilde kullanırsa bu durumun “apaçık” görünmesine, dolayısıyla patentlenmesinin zorlaşmasına yol açabileceğinden endişe etmiş olabilirler.
      Ama bu sadece tahmin.
      80'lerde IBM'de “Systems Engineers” denen kıdemli bir teknik kadro vardı ve tüm işleri belirli sistemlerin artılarını ve eksilerini yorumlamaktı.
      Sistem yazmak, debug etmek ya da açıklamak değil; sadece “bunu yanlış yapıyorsunuz” diye hüküm vermekti.
    • IBM'in şirket genelinde kurumsal normları genelde çok sıkı uyguladığı düşünülürse bu tuhaf görünüyor, ama IBM PC'nin kökenini anlatan kitaplara bakarsanız bunun Boca'daki PC organizasyonunun IBM standartlarına göre anormal bir istisna olmasıyla ilgili olabileceğini görebilirsiniz.
      Microsoft ekibine umutsuz derecede kurumsal bir yapı gibi görünse de, IBM içinde Boca ekibi “asi birlik” gibi görülüyordu; hatta IBM'in büyük kısmı onların varlığından bile habersizdi.
      IBM zaman ölçeğinde neredeyse bir gecede başlamıştı, inanılmaz hızla ilerliyordu ve Thomas Watson Jr. bunu, astlarının itirazlarını bastırıp böyle bir skunkworks'ü onayladığı için mümkün kılmıştı.
      Bu yüzden Boca'da, normalde o büyüklükte bir projede bulunacak gözetim, koordinasyon ve kontrolün çok azı vardı.
      İlk Boca ekibi normal raporlama zincirinin dışında hareket ediyordu; hatta IBM'in başka bölümlerinden teknoloji ya da parça almaya çalışırken gerçekten IBM'e bağlı olduklarını açıklamak zorunda kaldıkları bile oluyordu.
    • Hatırladığım kadarıyla IBM 3270 terminallerinde iki tane “Enter/Return” tuşu vardı.
      Biri bugünkü sıradan Return tuşu gibiydi; yalnızca bir sonraki alana geçerdi, formu göndermezdi.
      Bir diğer Enter tuşu ise bugünkü sağ Ctrl konumundaydı ve formu o gönderirdi.
      Yani IBM aslında Tab tuşunun kendisine değil, 3270 kullanıcılarının bir sonraki alana geçmek için kullandığını düşündüğü Return tuşunun form gönderme tuşu yapılmasına karşı çıkmış olabilir.
      DOS programlarında da bu çok yaygındı; Return'a basınca form gönderilmez, bir sonraki alana geçilirdi ve Windows'ta alışılması gereken şeylerden biri buydu.
    • İşin komiği, IBM bunu zaten daha önce yayımlamıştı.
      CUA, Tab ve Backtab'in alanlar arasında dolaşmak için kullanıldığını açıkça söylüyor.
      Yani IBM kendi standardına karşı 7 katmanlı yönetim zinciri çıkararak itiraz etmiş oldu: https://archive.org/details/ibmsj2703E/page/n13/mode/2up
  • Tab'ı tercih eden biri olarak tartışma çıkarmaya çalışmıyorum, ama yıllar önce Twitter'da Brendan Eich'e neden boşlukları tercih ettiğini sormuştum.
    Verdiği yanıt beklediğimden daha düşünceliydi.
    Modern işletim sistemleri ve kullanıcı arayüzleri Tab tuşunun kendisini yakaladığı için, özellikle tarayıcı gibi bağlamlarda gerçek tab karakteri girmek zorlaşıyor.
    Ben yine de Tab seven ve Go yazan biriyim, ama bunun gerçekten sinir bozucu bir sorun olduğu konusunda tamamen haklıydı.
    Örneğin Hacker News'in metin alanına tab karakteri koymaya çalışınca bunu hemen görürsünüz.

    • Yine de literal tab karakteri kullanmayan insanlar bile kod yazarken Tab tuşuna basmıyor mu? Yoksa gerçekten boşluğu N kez mi basıyorlar?
      İddiayı bir ölçüde anlıyorum, ama tab/boşlukların önemli olduğu kodu HN metin alanında yazıyorsanız, zaten başlı başına yanlış bir şey yapıyorsunuz demektir.
      Bir kod editörü Tab tuşunu düzgün şekilde işler.
      Buna karşılık Enter için Shift+Enter, Alt+Enter, Cmd+Enter gibi belli ölçüde yerleşik alışkanlıklar var, ama işletim sistemi genelinde kullanılabilecek bir tab karakteri girme yönteminin neredeyse hiç olmaması hâlâ sinir bozucu.
      Shift/Alt/Ctrl+Tab de genelde başka işlevler tarafından zaten yakalanmış oluyor.
    • “Tab” ile “sonraki alan” için ayrı tuşlar ve “satır sonu” ile “gönder” için de ayrı tuşlar olması mantıklı olabilir.
      Ama tab ve satır sonu her bağlam için geçerli değil.
      Ayrıca bazı programlarda ^V kullanımına benzer biçimde, kontrol karakterlerini komut olarak değil veri olarak girmek için bir tuş ya da tuş kombinasyonu da mantıklı olabilir.
      Mevcut bilgisayarlara benzemek zorunda olmayan yeni bir bilgisayar tasarlarken düşünmeye değer unsurlar bunlar; ben de bunları düşündüm, hatta gerçekten dikkate alabilirim.
    • Çoğu insanın Tab tuşunun doğru seçim olduğunu düşünmesi, bunun neden doğru seçim olmadığını gösteren mükemmel bir örnek aslında.
      Tab tuşunun özgün bir amacı vardı ve ona el kondu; bu da gerçek amacını kullanmayı zorlaştırdı.
      Apple'ın ilk Touch Bar çıktığında Escape tuşunu ortadan kaldırmasıyla çok da farklı değil.
      Ortalama kullanıcı o tuşu neredeyse hiç kullanmayabilir, ama ortalama bir geliştirici için o tuşun asıl amacı olmadan uzun süre yaşamak zordur.
    • İngilizce ana dilim değil; Brendan'ın ne dediğini anlamaya çalışıyorum.
      Eskiden tab karakterinin sistemden sisteme farklı görünebildiği, bu yüzden her zaman aynı görünen boşlukların daha güvenli olduğu söylenirdi.
      Brendan'ın kastettiği şey bu muydu?
    • İnsanların tab genişliği ayarlarını aynı yapmaması da ayrı bir sorun.
  • Harika bir yazı ama IBM'in neden Tab tuşunun bu şekilde kullanılmasına karşı çıktığını hâlâ merak ediyorum.
    Tab'ın hem giriş karakteri hem de kontrol karakteri olmasını istememelerinden mi?
    Yani bazı giriş alanlarında Tab yazılabilirken bazılarında yazılamıyor olmasının, hangisinin hangisi olduğunu anında anlamayı zorlaştırmasından mı?
    2026 yılında bile bu bakış açısına sempati duyabiliyorum.

    • Ben şahsen alanlar arasında geçiş için Tab kullanılmasını sevmiyorum.
      Birinci sebep DOS'taki uyumluluğun bozulmasıydı.
      DOS programları Enter kullanırdı ve numerik tuş takımında da Enter vardı; böylece sayısal veri tek elle girilebilirdi.
      Sol eliniz kâğıt kaynakta durur, sağ elle giriş yapardınız ve insanlar bunda çok hızlanmıştı.
      Bu desen Excel gibi bazı programlarda hâlâ yaşıyor.
      Birçok müşteri iki elini birden klavyeye koymak zorunda olmaktan hoşlanmazdı; bu yüzden birçok programımızda Enter=Tab eşlemesi vardı.
      Önemli olan tuşun “adı” değil, konumudur.
      Tuşun iki amaçlı olması sadece katlandığımız bir rahatsızlıktır; bazen gezinme tuşu gibi davranır, bazen de boşluk giriş tuşu gibi.
      Aynı sorun Enter için de geçerli olurdu.
      Açık ara en iyi çözüm klavyeye yeni bir tuş eklemekti; mümkünse bunu numerik tuş takımına koymak daha iyi olurdu.
      O dönemde birçok yeni tuş eklendi; geriye dönüp bakınca, o sırada “sonrakine geç” diye bir tuş da eklenmeliydi.
    • Tarayıcı içinde çalışan bir metin editörü tasarlıyorsanız, kullanıcıların Tab tuşunun işlevine dair beklentilerini tamamen bozmak zorunda kalırsınız.
      Çünkü böyle bir ortamda Tab tuşunun yerine getirebileceği tamamen mantıklı ve sezgisel iki rol vardır ve bunlar birbiriyle çakışır.
      Aynı sorun Enter tuşunda çok daha sık yaşanır; bugün bile ctrl+crlf'nin satır sonu mu yoksa mesaj gönderimi mi olduğu, tek başına crlf ile shift+crlf'nin ne yaptığı gibi epey karmaşık kuralları ezberliyoruz.
      HN editöründe shift+crlf ile tek başına crlf satır sonu oluşturur, ctrl+crlf ise hiçbir şey yapmaz.
      Ama başka yerlerde ctrl+crlf form ya da mesaj gönderimini tetikler, shift+crlf ham satır sonu ekler, tek başına crlf ise bunlardan biri olabilir, ikisi de olmayabilir.
      Yaygın bağlama böyle olsa da bunun istisnalarını ve ters çevrilmiş hâllerini gördüm; hatta shift+crlf'nin form gönderdiği, ctrl+crlf'nin ise ham satır sonu eklediği yerler de oldu.
      Bunların hepsi gerçekten sinir bozucu ve kullanıcı sürtünmesini ciddi biçimde artırıyor; bir dönem Microsoft stil kılavuzu, bugün insanlara ironik gelebilse de, en iyi uygulamalar için temel referanslardan biri sayılıyordu.
    • CAPSLOCK'un “sonraki giriş öğesini seç” için kullanıldığı ve TAB'ın karakter olarak kaldığı bir dünya hayal ediyorum.
    • Evet, buna o gözle bakılabilir.
      İçinde sayısız hareketli parça bulunan bir organizasyonu yönetmek ile kullanıcılar için hızla bir şey üretmek açıkça çok farklı önceliklere sahip.
    • Benim okuduğum kadarıyla ortada tam anlamıyla bir “IBM gerekçesi” yoktu.
      Daha çok, IBM bürokrasisinden biri araya girip işi durdurmuş ve bu da kültür farkını göstermiş gibi geldi.
      Sonuçta yazının kendisi de zaten bu kültür farkı üzerineydi.
  • IBM, MS-DOS'un seçeneklerde neden “-” desteklemediğinin ve aygıtların tüm sürücülerdeki “\DEV” dizininde yer almamasının da sebebi.
    “/” karakterinin yol ayırıcı olarak desteklenmesi ise kaldı.
    Microsoft'taki birçok kişi Xenix kullanıyordu ve Unix hayranıydı; çok erken dönem DOS'ta bunun için SWITCHCHAR ve AVAILDEV config.sys seçenekleri bile vardı.
    Ama bildiğim kadarıyla IBM buna ciddi şekilde karşı çıktı ve kaldırılmasını zorladı.
    Özellikle DEV meselesi can sıkıcı, çünkü DOS 1'de dizinler bile yoktu; yani büyük bir uyumluluk sorunu olması mümkün değildi.
    Ama bunun sonucu olarak DOS/Windows, aygıt dosyalarının her dizinde var olduğunu varsaydığı için “CON” ya da “COM1” adında dosya oluşturulamaması gibi bir mirasa mahkûm kaldı.

    • Microsoft bunu MS-DOS'tan hiçbir zaman çıkarmadı.
      Sadece uzun yıllar bunun için gerekli çağrıları belgelemedi.
  • Mainframe 3270'te Tab tuşunun alanlar arasında geçmek için kullanıldığını hatırladığım için bu bana garip geldi.

    • Evet.
      Operator's Guide PDF'ini buldum.
      https://news.ycombinator.com/item?id=48028227 bağlantısına bakın.
    • Ben de hep IBM standardının TAB ile ilerlemek ve ENTER ile formu onaylamak olduğunu düşünürdüm.
    • Benim anım da tam olarak böyle.
      Tab kullanmak neredeyse ikinci doğa gibiydi ve GUI uygulamalarına geçtiğimde, özellikle Visual Basic uygulamalarında tab sırası bozuksa çok sinir bozucu olurdu.
    • IBM green screen kullanalı uzun zaman oldu ama bizim uygulamalarda Tab'ın alanlar arasında gezindiğini hatırlıyorum.
      Yine de bu amaç için ayrılmış işlev tuşları da vardı galiba.
    • Midrange sistemlerde durumun nasıl olduğunu merak ediyorum.
      AS/400 hiç kullanmadım ama ayrı bir Field Exit tuşu kavramı olduğunu sanıyorum.
  • “Microsoft'takiler IBM'dekileri anlamsız bürokrasiye saplanmış insanlar olarak görüyor, IBM'dekiler de Microsoft'takileri disiplinsiz hacker'lar olarak görüyordu” kısmı beni çok güldürdü.
    MSFT'de çalışıyorum; o dönemin Microsoft'u bugünkünden çok farklı bir şirket gibiymiş.
    Şimdi ise sonsuz toplantılar, yapay zeka talimatları, terfi tiyatrosu derken ben ve çalışma arkadaşlarım kendimizi anlamsız bürokrasinin içinde sıkışmış hissediyoruz.
    Maaş iyi ama bürokrasi insanın ruhunu emiyor.

  • Tüm makinelere bir oyun kolu bağlayıp yön tuşlarıyla alanlar arasında geçmeli, ‘A’ tuşuyla hiyerarşik menülerde bir seviye yukarı çıkmalı, ‘B’ ile de alt menüye girmeliyiz.
    Böylece alanlar arasında geçmek için veriyi girdikten sonra ellerinizi klavyeden çekip oyun kolunu alır, sağ ya da sol tuşa basar, sonra tekrar klavyeye dönersiniz.
    Verimlilik kesinlikle tavan yapar.

    • Şuna da bakın :) https://github.com/madewokherd/xalia#default-gamepad-control...
      Amaç, standart işletim sistemi denetimlerini kullanan video oyunlarının gamepad ile doğal şekilde kontrol edilmesini sağlamak.
    • Gerçekten harika fikir.
      Kesin patentlenmeli.
      O zamana kadar da ikinci en iyi seçenek olan fareyi kullanırız.
  • 30 yıldan uzun süredir Mac kullanıcısıyım ama Raymond Chen'in tarih yazılarını gerçekten seviyorum.
    folklore.org'u biliyorum; keşke Apple içinde de onun karşılığı bir şey olsa.
    Ne yazık ki bu, Apple kültürünün bir parçası değil.

    • Apple kültürüne yapacak bir şey yok, ama üzerinden yeterince zaman geçtiğine göre bir hikâye paylaşsam herhalde kimse sorun etmez.
      1992'de System Software ekibinde yaz stajyeriydim ve projelerimden biri, disk ilklendirme sırasında bulunan bozuk blokları işaretleyen Disk Initialization Package özelliğini geliştirmekti.
      Mevcut özellik çalışıyordu ama çok yavaştı, ilerleme göstermiyordu ve iptal edilemiyordu.
      En zor kısmı kullanıcı arayüzüydü.
      Hızı epey artırdım ama tüm sürecin ne kadar süreceğini bilmek mümkün olmadığından, kalan süreyi göstermeye çalışan tüm sezgiseller berbattı.
      Birkaç sıra ötede unvanı “User Interface” olan birini gördüm ve yardımcı olup olamayacağını merak ettim; biraz vakti olup olmadığını sordum ve Apple çalışanı #4 olan, ayrıca iki Steve'i birbiriyle tanıştıran Bill Fernandez ile oturup problemi çözdük.
      O yaz tanıştığım insanlar içinde, yöneticim dışında açık ara en nazik kişiydi; problemi anında tam olarak kavradı ve mükemmel bir çözüm üretti.
      Kalan süre tahmininden vazgeçip, her disk izini test ettikçe ilerleyen bir belirsiz ilerleme çubuğu kullanmayı önerdi.
      İşe yaradı, insanlar beğendi ve 7.1'den sonraki bir ara sürüme girdi.
      Raymond'ın yazıları kadar şaşırtıcı değil belki, ama başlangıç için yeterli.
  • Her dönemin neredeyse her ayrıntı üzerine kavgalarla dolu olması bana etkileyici geliyor.
    Tuşlar da buna dahil; düzenleri, şekilleri, anlamları, her şeyi.
    Ama bugün artık kimsenin bunları umursamıyor olması hem çok garip hem de komik.

    • Tahoe'daki glassmorphism tartışmalarını görmedin mi?