Jeffrey Snover’ın PowerShell geliştirme hikâyesi

 (corecursive.com)
1 puan yazan GN⁺ 2024-07-05 | 1 yorum | WhatsApp'ta paylaş
  • Jeffrey Snover, Windows’u komut satırından yönetilebilen bir sunucu işletim sistemi haline getirmek için PowerShell’i ileri taşıdı ve GUI odaklı Microsoft kültürüyle kurumsal direnci aşmak zorunda kaldı
  • İlk dönem UNIX araçlarını taşıma girişimi, Windows’un dosyalardan çok Registry, Active Directory, WMI gibi API’lere dayanan yapısı nedeniyle sunucu yönetimi sorunlarını çözemedi
  • WMIC’te WMI tabanlı 70 komut oluşturduktan sonra, test darboğazını ve maliyet sorunlarını azaltmak için meta veri tabanlı komut üretim motoru yönüne geçti
  • PowerShell’in öncülü Monad, .NET ve Longhorn akışıyla başladı; ancak Longhorn sıfırlamasından sonra Windows’tan dışlandı ve Exchange ekibi ile Windows Server organizasyonunun desteğiyle yeniden hayata döndü
  • Snover, unvan ve ücret kaybını göze alarak PowerShell 1~4’e odaklandı; bu araç, Windows yönetim otomasyonunun ve Office’in buluta geçişinin temeli oldu

GUI odaklı Windows ve veri merkezi yönetimi sorunu

  • PowerShell, Windows sistem yönetimini değiştiren bir komut aracıydı; ancak Microsoft içinde baştan beri doğal biçimde kabul gören bir proje değildi
  • O dönemde Microsoft kültürü GUI odaklıydı ve Bill Gates’in command.exeyi son kez göreceğini söylediğine dair bir anekdotun çıkacak kadar komut satırı arayüzü eski bir şey olarak görülüyordu
  • Snover’ın Microsoft’a katılma noktası, Windows NT tabanlı işletim sistemini veri merkezi ve kurumsal pazara uygun hale getirme gerekliliğiydi
    • Amaç, Sun, IBM ve HP gibi UNIX satıcılarıyla rekabet etmekti
    • Intel ve açık donanım ekosistemi maliyet açısından avantajlıydı, ancak sunucu yönetim yazılımı yeterince iyi değildi

Sistem entegratörlerine bağımlılığı azaltan yönetici modeli

  • Windows sunucu yönetiminde çok sayıda sunucunun tıklayarak yapılandırılması gerekiyordu ve her şirketin ihtiyaç duyduğu yapılandırma farklı olduğu için sistem entegratörlerine bağımlılık büyüyebiliyordu
  • Snover, entegratör maliyeti yükselirse Windows’un fiyat avantajının ortadan kalkacağını düşünüyordu
    • Örnek olarak donanım 10, yazılım 2, sistem entegratörü 40 şeklinde bir maliyet yapısından söz etti
    • Müşteri ilişkisi ve değerin entegratörlere kayması da ayrı bir sorundu
  • Alternatif, UNIX tarzı programcı yönetici modeliydi
    • Küçük araçları birleştirerek özgün sorunları çözme ve otomasyon yapma yaklaşımı
    • Windows’ta da yalnızca “ileri” düğmesine basan yöneticiler değil, script ve otomasyonla çalışan uzman bir yönetici katmanına ihtiyaç vardı

UNIX araçlarını taşımak neden uymadı

  • İlk çözüm, Windows Services for Unix ile UNIX shell’ini ve AWK/GREP/SED gibi araçları Windows’a taşımaktı
  • Ancak Windows’un yönetim yapısı UNIX’ten farklıydı
    • UNIX, dosya merkezli bir işletim sistemiydi; bu yüzden dosyaları değiştirip süreçleri yeniden başlatarak birçok yönetim işi yapılabiliyordu
    • Windows ise Registry, Active Directory, WMI gibi işlevlerin API’lerin arkasında olduğu bir yapıya sahipti
    • AWK, Registry’ye; SED, Active Directory’ye; GREP ise WMI’a doğrudan uymuyordu
  • WMI, yönetim işleri için potansiyel taşıyordu ama yaygın kullanılmıyordu; Snover’ın ekibi de WMI nesnelerini işleyen bir komut satırı aracı yapmaya çalıştı

WMIC ve meta veri tabanlı motor

  • Windows XP döneminde, yalnızca 10 haftalık kod yazma penceresi içinde WMI tabanlı bir komut satırı arayüzü geliştirmek gerekiyordu
  • Sözleşmeli mühendislerden yararlanarak 70 görevi hayata geçirdiler; ancak bu, tüm Windows sunucu yönetimi için gereken kapsamın çok uzağındaydı
  • Microsoft içinde test organizasyonu onay vermezse bir özellik yayımlanamıyordu ve komut sayısı arttıkça test darboğazı da büyüyordu
  • Snover, HTML ile tarayıcı arasındaki ilişkiye benzer şekilde, tek tek komutları kod değil meta veri olarak görüp yalnızca ortak motoru test etme yaklaşımını savundu
    • Motor komutları üretecek, her komutun ayarı ise XML benzeri bir meta veri biçiminde ifade edilecekti
    • Noel tatili boyunca meta verileri yazarak 72 komut oluşturdu
    • Sonradan anlattığına göre mevcut 70 komut yaklaşık 4 milyon dolara, motor ise yaklaşık 60 bin dolara mal olmuştu
  • Motora filtreleme ve biçimlendirme gibi işlevler eklendikçe tüm komutlar birlikte gelişti; bu da PowerShell mimarisinin önemli bir habercisi oldu

Longhorn, .NET, Monad

  • Bill Gates, Windows 98 kullanıcılarının XP’ye yeterince geçmediğini görünce Longhorn’u yeni bir Windows 95 benzeri dönüm noktası yapmak istedi
    • Longhorn’da .NET tabanlı geliştirme yaklaşımı, WPF, WCF ve yeni depolama modeli gibi bileşenler yer alacaktı
  • Snover, .NET’in Windows yönetiminin kapsamını genişletmenin bir aracı olabileceğini düşündü
    • WMI provider yazımı yeterli ivmeyi kazanamamıştı, ancak Bill Gates .NET benimsenmesini güçlü biçimde itiyordu
    • Yönetim yardımcı araçları .NET üzerine kurulursa daha geniş kapsama ulaşılabileceğine inanıyordu
  • Başka bir organizasyon K-shell’i taşıyıp bir shell yapmak isteyince, Snover daha iyi yaklaşımı anlattı ama ikna etmeyi başaramadı
  • Bunun üzerine bir odaya kapanıp yaklaşık 10 bin satırlık bir prototip geliştirdi; PowerShell’in temel mimari ilkeleri bunun içindeydi
    • Demodan sonra ilgili ekip fikri benimsedi ve Snover bunun hayatındaki en iyi fikir olabileceğini düşündü
    • Bu projeye katılmak için yüzlerce ila bin kişilik ürün ve hizmetlerin chief architect rolünü bıraktı ve fiilen tenzili rütbeyi kabul etti

Monad Manifesto ve ekibi ikna etme

  • Yeni ekip proje adını Monad koydu ve personel yetersizliği nedeniyle bazı işleri Hindistan’a dış kaynak olarak verdi
  • Snover, proje vizyonunu ve başarı yolunu hizalamak için Monad Manifesto’yu yazdı
    • Sorunu, mevcut yaklaşımı, yeni yaklaşımı, değeri ve farklılaştırıcı noktaları düzenledi
    • Yöneticiler, provider’lar, geliştirme ekipleri gibi paydaşların her birine hangi değerin sunulduğunu açık biçimde ortaya koydu
  • Microsoft’taki her ekibin zaten çok işi vardı; komut satırı arayüzü yapmasalar işten çıkarılmıyorlar, yapsalar da bunun terfi getireceği düşünülmüyordu
  • Monad’ın önerisi, her ürün ekibinin yalnızca kendi nesnelerini işleyen kodu yazması, geri kalan her şeyi ise PowerShell’in sağlamasıydı
    • Biçimlendirme, sıralama, filtreleme, parser, uzaktan çalıştırma, yetki yükseltme gibi unsurları PowerShell tarafı sağlayacaktı
    • Her ekibin yalnızca kendi alan nesnelerinin nasıl işleneceğini bildirmesi yeterliydi
  • Active Directory ekibi birkaç haftalık yatırımla birkaç cmdlet hazırladı ve kullanıcı gruplarından güçlü tepki gelince daha fazla çalışma yaptı

Longhorn sıfırlamasından sonra Windows’a geri dönüş

  • Longhorn’da .NET benimsenmesi aşırı zorlanınca sorunlar büyüdü
    • Örneğin Notepad’in Save As iletişim kutusu, .NET/WCF tabanlı ortak diyalog nedeniyle 1 dakika 30 saniye sonra açılıyor ve çalışma kümesi 15KB’den 15MB’ye çıkıyordu
    • Gece derlemelerinin yaklaşık 7 ay boyunca çalışmadığına dair bir anlatım da var
  • Windows organizasyonu sıfırlamaya giderek .NET kodunu Windows’tan çıkardı ve PowerShell de Windows dışına itildi
  • Sonrasında PowerShell, hem komut satırı arayüzü olması hem de .NET tabanlı olması nedeniyle tekrar tekrar iptal baskısıyla karşılaştı
    • Bill Gates değeri anlıyordu ama günlük savunmada yardımcı olamıyordu
    • Windows Server yöneticisi kritik anlarda destek verdi
    • Exchange ekibi, PowerShell’e bağlı “milyarlarca dolarlık iş” vurgusuyla iptali engelleyen taraf oldu
  • Windows’a .NET koymak için WinArch gereksinimleri çok katıydı; ancak PowerShell ekibi tüm koşulları karşılayacak şekilde hazırlandı
  • Windows yöneticisi talebin geri çekilmesini isteyince program yöneticisi resmî ret talep etti ve bunun sonucunda bir inceleme süreci açıldı
    • Karar yetkisi Windows Server organizasyonundaydı ve PowerShell’in gereksinimleri karşıladığına karar verilince yeniden Windows’a dahil edildi

PowerShell 1~4 ve gerçek etkisi

  • PowerShell 1, Windows Vista’nın bir parçası olarak yayımlandı
  • Snover, yayımdan sonra başka işlere geçmesi yönünde tavsiye ve kariyer açısından zarar göreceğine dair uyarılar aldı; ancak PowerShell 2, 3 ve 4 boyunca aynı vizyona odaklanmayı sürdürdü
    • Sonradan anlattığına göre sürüm 1 bazı hedeflere ulaştı, sürüm 2 ve 3 eksikleri tamamladı, sürüm 4 ile vizyon neredeyse bütünüyle tamamlandı
  • PowerShell, Windows yöneticilerinin script yazmasını ve karmaşık işleri otomatikleştirmesini sağladı
    • Kullanıcı grupları, çevrimiçi soru-cevaplar, script paylaşımı ve konferans sunumları ortaya çıktı
    • Bazı yöneticiler PowerShell deneyimi sayesinde profesyonel konuşmacıya dönüştü
  • Snover yaklaşık 5 yıl sonra Distinguished Engineer oldu, ardından Technical Fellow unvanını aldı
  • Office yöneticisi, PowerShell olmasaydı Office’in buluta geçişinin zor olacağını, Office’in buluta geçişinin de Azure’un bulut dönüşümünü etkilediğini söyledi
    • Daha önce sunucu sağlama işlemi tıklama tabanlıydı; bu da tekrar etmeyi ve düzeltmeyi zorlaştırıyordu
    • Script’ler sayesinde ölçeklenebilirlik sağlandı ve sorun çıktığında script değiştirilerek yanıt verilebildi

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-05
Hacker News yorumları

  • Sunucu açısından bakıldığında, PowerShell Microsoft içinde çok sert bir muhalefetle karşılaştı ve onu yapan Jeffrey Snover bunu zorlayarak ilerletmeye çalışırken rütbe düşürülmesine kadar varan sonuçlar yaşadı.
    Jeffrey aslında Microsoft'un veri merkezinde rekabet etmeyi öğrenmesine yardımcı olması için işe alınmıştı, ancak o dönemin kültürü kişisel bilgisayar merkezli dünya görüşüne fazlasıyla bağlı olduğundan her adımda dirençle karşılaştı.
    Bir başka ilginç nokta da PowerShell'in, Windows dosya tabanlı olmadığı için ortaya çıkmış olması. Jeffrey'nin hedefi sunucu yönetimiydi; ancak Windows'ta yalnızca yapılandırma dosyalarını düzenleyerek yönetim yapmak mümkün değildi, çeşitli API'leri çağırıp yapılandırılmış veriler alıp vermek gerekiyordu. Bu yüzden zengin bir nesne modeli fiilen tek yoldu.
    Transkript, profesyonel dökümden Descript'e, ardından GPT-4 ile noktalama düzenlemesine ve son olarak elle gözden geçirmeye uzanan bir süreçle hazırlandı; kalitesi beklendiği kadar yüksek olmayabilir.

    • MS-PWSH ekibi bunu görürse, çok fazla .NET kodunu doğrudan yazmaya gerek bırakmayacak temel GUI özellikleri eklemelerini isterdim.
      PowerShell'i sevmemin nedeni basit bir dinamik dil olması ve kullanımı kolay komutları birbirine bağlayabilmem; bu yüzden basit kullanıcı arayüzleri ve grafikler oluşturmak için yeni bir cmdlet kümesi güzel olurdu.
      Örneğin Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" gibi bir özelliğin Microsoft'un ürüne eklemesi kolay görünür ve pek de anlamadığım bir sayfalık boilerplate kodu ortadan kaldırabilir.
      Temel düzeyde programlama yapabilen ama Java veya C# gibi araçların işiyle örtüşmediği milyonlarca kullanıcı vardır. Python genelde iyi uyuyor, ancak Microsoft'un yalnızca sunucu yöneticileri veya IT çalışanları için değil, genel ofis kullanıcılarının da kullanabileceği daha fazla şey geliştirmesini isterdim.
      Microsoft, PowerShell'in dosya ayrıştırma gibi işlerde yavaş kalmaması için daha fazla yatırım yapar ve yukarıda bahsedilen özelliklerin yanı sıra istatistik ve bilimsel kullanım için cmdlet'ler de eklerse, sıradan bir iş analistinin iş süreçlerini iyileştirecek yazılımları ya da geliştirme ekibine devredeceği prototipleri hızlıca oluşturabileceği epey güçlü bir araç haline gelebilir.
      Microsoft sanki seçenekleri C# kullanan tam zamanlı yazılım geliştirici, PowerShell kullanan IT işleri ve iş kullanıcıları için Excel olmak üzere üçe ayırıyor. Excel birçok açıdan harika ama oldukça sınırlı; VBA+Excel ise uğraştığım ekosistemler içinde en kısıtlayıcı olanlardan biri. Python ve R gibi üçüncü taraf diller dördüncü bir seçenek olsa da Microsoft'un bu alana daha fazla zaman ayırmasını isterdim.
    • GitHub'da MVP'lerin, Microsoft'un vaat ettiği ek yatırımların gerçekleşmediğinden, değişikliklerin yansımadığından ve iyi özelliklerin kaderine terk edildiğinden şikâyet ettiğini görünce artık MSFT'nin önceliği değil gibi görünüyor.
      PowerShell'i tuhaf kusurlarıyla birlikte seviyordum ama artık bıraktım.
    • Python veya benzeri mevcut araçlar yerine neden sıfırdan yeni bir şey yaptıklarını merak ediyorum.
    • Transkripti okumaya çalıştım ama sonuna gelemedim; okumayı biraz zor buldum.
      Okurken makine tarafından üretildiğini tahmin ettim ama nedenini somut olarak söylemek zor; daha okunabilir olması için biraz düzenleme gerekiyor gibi.
      Yine de hiç transkript olmamasından çok daha iyi.

  • Uzun süredir Bash kullanan bir geliştirici olarak PowerShell çıktığında gerçekten heyecanlanmıştım
    Sonunda Windows’ta da geliştirme için harika bir shell kullanabileceğimi düşünmüştüm ama sonrasında PowerShell’i doğru dürüst içselleştiremedim ve Windows’ta da alışık olduğum Bash’i kullanmaya devam ediyorum
    İki shell’e de hâkim geliştiricilerin bunları nasıl karşılaştırdığını merak ediyorum. PowerShell’in daha verimli ve modern bir shell olma vaadini gerçekten yerine getirip getirmediğini, yoksa varsayılan kurulu geldiği ve CMD’den daha iyi olduğu için mi kullanıldığını bilmek istiyorum

    • Bash’i çok kullandım ve birkaç kitap da okudum ama karmaşık Bash scriptleri yazılmaması gerektiğine kesinlikle inanıyorum
      Yaklaşık 50 satırı aşınca bunu code smell olarak görüyorum ve birini ikna etmem gerekirse diye şu sayfayı kaydetmiştim: http://mywiki.wooledge.org/BashPitfalls
      Son zamanlarda PowerShell’i deneyince, komutların metin değil nesne döndürmesi ve bu yüzden metni zorla işlemek zorunda kalmamak, onu hem script dili hem de komut satırı dili olarak çok daha kolay hale getirdi
      Argüman ayrıştırmayı ele alan resmi bir yolun olması da harika. Her şey tutarlı ve komut satırı penceresinde neredeyse tüm seçenekleri otomatik tamamlayabiliyorsunuz; Bash’in hayal bile edemeyeceği bir seviye, bu yüzden üretkenliği çok artırıyor
      Ancak tür dönüşümü Bash’te olmayan yeni hatalar da yaratabiliyor. Şu anda PWSH’yi daha çok tercih ediyorum ama ikisinden de bir ölçüde hoşlanmıyorum ve bir sonraki doğal evrimi bekliyorum
    • PowerShell, Bash’ten daha laf kalabalığına sahip ve 0 ya da 1 elemanlı dizileri beklenmedik anlarda otomatik olarak skalar değere açması gibi tuhaflıkları var; ancak daha üretken ve okunabilir
      Nesne yönelimli yapı, pipeline oluştururken epey işe yarıyor
      Örneğin bir klasör içinde dosya boyutlarına göre özyinelemeli gruplar oluşturup olası kopyaları bulmak için Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count gibi yazabilirsiniz
      Anlaşılması zor file büyülerini hatırlamaya ya da metin çıktısını parse etmeye gerek yok. Özellikleri olan gerçek nesneler alırsınız ve sekmeyle otomatik tamamlama bu yapıyı görebilir
      JSON parse etmeniz gerekiyorsa jq olmadan doğrudan Get-Content -Raw whatever.json | ConvertFrom-Json ile işleyebilirsiniz. XML’i CSV’ye çevirmek için ConvertFrom-Xml veya Select-Xml sonrasında gereken işlemleri yapıp ConvertTo-Csv kullanabilirsiniz
      Get-ChildItem çok uzunsa gci, dir, ls kullanabilirsiniz; Where-Object uzunsa where ya da ? kullanabilirsiniz. Varsayılan olarak büyük/küçük harf de ayırt etmez
    • Kariyerime SunOS pizza kutularının X terminalinde başladım, binlerce script yazdım ve bunların önemli bir kısmı binlerce satır uzunluğundaydı
      Birkaç yıl önce PowerShell ile karmaşık, gözetimsiz çalışan, sağlam bir veri aktarım sistemi yazmam gerekti; bu deneyim o kadar iyiydi ki macOS ve Linux’taki tüm shell’lerimi PWSH’ye çevirdim
      En sevdiğim nokta nesneleri pipeline üzerinden aktarma gücüydü. İlk filtrede nesnenin bazı özelliklerini çıkarıp değiştirdikten sonra bile, pipeline’ın ilerideki filtrelerinde başka özelliklere ve ilk filtrenin oluşturduğu nesne özelliklerine erişmeye devam edebiliyordum
      Komutların, hata işlemenin ve nesne özelliklerinin tutarlılığı da çok iyiydi
      Daha sonra işimin niteliği değişince eski kas hafızam geri geldi ve tüm shell’lerimi Bash’e döndürdüm. O alanda çok çalışıp düşünürken PWSH bir shell olarak doğal geliyordu; ama oradan uzaklaşınca PWSH ile düşünmek, Bash’e geri dönmekten daha zor hale geldi
      Bazen özlüyorum. Shell alanında buna bu kadar yaklaşan başka bir şey yok; en azından geçiş çabasını haklı çıkaracak kadar yakın bir alternatif olmadığını düşünüyorum
    • İkisinde de uzman değilim ama epey kullandım ve PowerShell’in birkaç tuzak yüzünden kullanmasının berbat hale geldiğini düşünüyorum
      Birincisi, bir .NET dili olmaya çalışması. Tek runtime ve birden çok dil vaadinin Java tarafında böyle bir vaat olmadan bile neden serpilip .NET’te solduğunu bilmiyorum; ama .NET kodu yazacaksam C# yazmanın daha iyi olduğunu düşünüyorum
      İkincisi, shell’in temel özelliklerini doğru oturtamamış olması. Ayrıntılar artık geçmişte kaldığı için hatırlamıyorum ama yönlendirme işleyişi bozuktu ve Bash’te önemsiz olan şeyler PowerShell’de neredeyse imkânsız düzeyindeydi. Geliştiricilerin yeni ve güçlü bir şey yapma heyecanıyla Bash ve benzerlerinin iyi yaptığı şeyleri göz ardı ettiğini hissettim
      Üçüncüsü, tüm adlarda Verb-Object biçimini zorunlu kılmak gibi bir takıntısı var. Öznel bir konu ve savunanları da olacaktır ama bunun scriptleri çirkinleştirdiğini, yazmayı da tuhaflaştırdığını; keşfedilebilirliği ya da hatırlanabilirliği de pratikte iyileştirmediğini düşünüyorum
    • Bash’ten çok farklı biçimlerde şaşırtan sayısız nokta olduğu için PowerShell’i sevmiyorum
      Sekme yerine sağ ok kullanmak zorunda kalmak da kafa karıştırıcı; alışıldık komutların olmaması ve adlandırmada katı kurallar bulunması da rahatsız edici
      Yine de iyi bilirseniz PowerShell, Bash’ten daha yetenekli görünüyor. Daha iyi bir tür sistemi var ve argümanlarla çalışmak daha kolay; buna karşılık Bash’teki değerler daha çok biçimsiz dizelere benziyor
      https://github.com/bionicles/tree_plus/blob/main/tests/more_... Windows makinesinde test ortamı kurarken kullandığım biraz eski bir sürüm ve nelerin mümkün olduğunu bir ölçüde gösteriyor

  • PowerShell’ı doğrudan kullanırken korkunç bulmuyordum ama uzunluğu 1 olan bir dizinin neden diziden çıkarılıp içteki tipe dönüştüğünü anlayamamıştım.
    Bu yüzden diziye kaç öğe gelebileceğini her seferinde düşünmek zorunda kalıyordum; genel biçimde işlemek yerine her değişiklikte kontrol etmem gerektiğinden muazzam bug’lar oluşuyordu. Bunu neden böyle yaptıklarını bilen var mı, merak ediyorum.

    • Diziler etrafındaki gevşekliğin nedeni, cmdlet çıktı API’sinin de diziler konusunda gevşek olması.
      WriteObject adlı tek bir fonksiyon verilen değeri cmdlet’in çıktısı olarak yazar; bir kez çağrılırsa çıktı o olur. Birden çok kez çağrılırsa shell’in bu değerlerin hepsini toplayıp bir diziyi çıktı haline getirmekten başka seçeneği yoktur.
      Dolayısıyla bir cmdlet çalıştırmasında WriteObject yalnızca bir kez, başka bir çalıştırmada ise iki kez çağrılırsa, ilk durumda shell o tekil çıktıyı da diziyle sarmalaması gerektiği bilgisine sahip olamaz. Öte yandan cmdlet çıktısını her zaman diziyle sarmalamak, Get-Date gibi anlamsal olarak tek bir sonucu olan cmdlet’ler için engel olur.
      Her nedense cmdlet’in kendisinin, gerçek WriteObject çağrı sayısından bağımsız olarak anlamsal açıdan tekil çıktı mı yoksa çoklu çıktı mı ürettiğini ifade etmesini sağlayacak şekilde API’yi karmaşıklaştırmak istememişler gibi görünüyor. Böyle bir API, çıktısı parametrelere göre büyük ölçüde değişebileceği için cmdlet’in statik bir özelliği olamaz; boş dizilerde de çalışması gerektiğinden (Object, bool iMightWriteMoreValues) gibi bir WriteObject overload’u da sorunlu olur. Muhtemelen ayrı bir IWillWriteMultipleValues() fonksiyonu gerekirdi.
      Burada da açıklanmış: https://news.ycombinator.com/item?id=40874873
    • Bu gerçekten sinir bozucu. Diziyi zorlamak için başına virgül koyan comma hack’i kullanmaya başladım.
      $Ary = @(, "value")
      Dizi oluştururken, özellikle büyük dizilerde +=’dan daha performanslı olduğu için bir for döngüsünü diziye atama özelliği de oldukça iyi. Diziyi doldurmanın sezgisel bir yolu değildi ama kesinlikle yararlı.
      $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
    • Bu, yazılımın fazla akıllı olmaya çalışıp başarısız olmasının klasik bir örneği gibi geliyor.
      Yazılım geliştiriciler, yazılımlarını fazla akıllı yapma cazibesine karşı her zaman tetikte olmalı.
    • Yarım pişmiş bir özellik gibi hissettiriyor.
      Eksik kalan diğer yarısı, alıcı taraf bir dizi beklediğinde tekil bir değeri otomatik olarak uzunluğu 1 olan bir diziye dönüştürmek olurdu.
    • Niş dillerin her seferinde böyle çılgın tuhaflıkları oluyor gibi.
      Lua gibi bir şey zaten varken onu olduğu gibi kullanmak ya da biraz değiştirerek basit, küçük, zarif ve tutarlı bir dil elde etmek yerine, insanların tekerleği yeniden icat edip onu yuvarlak yapmayı bile başaramaması Sisifosvari bir trajedi gibi.

  • Windows alt sistemleriyle etkileşim kurmanız gerektiği için belirli PowerShell komutlarına ihtiyaç duymuyorsanız, “Neden Python kullanmıyorum ki?” diye düşünüyorum.
    Bash ile yapılacak işlerin %90’ı için fazla laf kalabalığı ve yavaş; başka bir hayatta Perl ile yapacağım işler için de aynı.
    Microsoft’un neden Python, Node gibi şeylerin üzerine inşa etmediğini sık sık merak ediyorum. PowerShell’in ilk ne zaman çıktığını hatırlamadığım için o dönemde neyin ideal olacağından emin değilim.

    • Python’ın varsayılan REPL’i gerçekten berbat.
      Ayrıca PowerShell’in iyi yaptığı konsol işleri için tasarlanmamış. Dosya içeriğini alıp başka bir komuta aktarmak yeterliyken dosya handle’ı yönetimi gibi şeyleri kendiniz yapmak zorunda kalıyorsunuz.
      PowerShell’in iyi olmasının nedeni; otomatik tamamlama sunan harika bir REPL’e sahip olması, garip boşluk davranışlarının olmaması, readline[0] ve gerektiğinde .NET ile yapılabilecek her şeyi yapabilen bir İsviçre çakısı olması.
      Üstelik nesne yönelimli olduğundan, eski bir yardımcı aracın metin tabanlı çıktısını başka bir eski yardımcı araçla nasıl parse edeceğinizi bulmaya çalışmak yerine asıl yapmanız gereken işe odaklanabiliyorsunuz.
      0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
    • Başlangıçta gevşek biçimde Perl ve Korn shell’i temel alıyordu.
      Bruce Payette’in “Powershell in Action” kitabının ilk baskısında, PowerShell’in @ işaretini, varsayılan değişken $_’yi ve fonksiyon çağırma operatörü &’yi kullandığı için Perl’e benzediğine dair bir yan açıklama var. Gerçekten de bir dönem Perl’i kök dil olarak kullanmış ve bu öğelerin o dönemden geldiği söyleniyor. Daha sonra sözdizimi C#’a daha uygun olacak şekilde değiştirildi, ancak bu öğeler iyi çalıştığı için korundu; Perl terminolojisiyle dilin “whipupitude quotient”ına büyük katkı yaptıkları anlatılıyor.
      Ayrıca PowerShell çekirdek dili Korn shell’in POSIX 1003.2 dilbilgisine dayanıyor; başlangıçta hash table gibi gelişmiş kavramlar için Perl deyimlerini almış olsa da proje ilerledikçe PowerShell sözdizimini C#’a uydurmanın daha uygun olduğu açık hale gelmiş.
    • PowerShell, Node’dan 3 yıl önce çıktı.
      Başka bir şeyin üzerine kurulmamasının nedeni muhtemelen Microsoft’un .NET’i kontrol ediyor olmasıydı.
      Yavaş olmasının nedeninin .NET olduğunu sanmıyorum; daha çok tasarım sorunu ya da performans yatırımı eksikliği gibi geliyor.
      Yine de hangi PS sürümünü kullandığınıza bağlı. Hatırladığım kadarıyla son sürüm oldukça hızlı.

  • İş yerinde 20 yılı aşkın SQL Server stored procedure kod tabanıyla uğraşma nimetine eriştim.
    Yaklaşık 300 bin satırlık, monkey testlerden geçmiş iş açısından kritik koddu; kaynak yönetimi yoktu, performans ayarı da hiçbir zaman doğru dürüst yapılmamıştı. SQL, SSMS içinde düzenlenip çalıştırılarak ortamlara dağıtılıyordu ve elbette otomatik test de yoktu.
    Şirket Windows ağırlıklı, geliştirme Mac üzerinde yapılıyor, GitHub Actions’ta ise Linux kullanılıyor.
    PowerShell Core, sqlcmd, Windows SQL Server instance’ı çalıştırmak için docker, mevcut legacy sunucudan şema ve kodu çıkarmak için RedGate SQL Compare, birim testleri için tSQLt, kod uyumluluğu için TSqlLint, stil uyumluluğu için SQLFluff, dağıtım için Flyway gibi araçları seçtik.
    Windows platformlardan biri olmak zorunda olduğunda PowerShell Core’un birlikte çalışabilirliği en iyi cross-platform scripting shell olduğunu kısa sürede anladım.
    Kod yazması keyifli değildi. Regex motoru .NET’ten geliyor ama ölümcül backtracking sorunları var; array davranışı da tuhaftı. Çalıştırılabilir dosyaları istediğim şekilde başlatmak ve çıktı stream’lerini yakalamak da tutarsızdı; çoğu zaman bir process çalıştırıp çıktıyı geçici dosyaya yönlendirmem, child process bitince de o dosyayı okumam gerekiyordu. Child process’in standart çıktısını string değişkene pipe etmek bile gereğinden fazla zahmetliydi.
    Ama PowerShell Core hızlı çalışıyor. Microsoft’un iyi yaptığı bir şey varsa o da mikro optimizasyon. ASCII art liste seçici ya da kolay input prompt üretici gibi kullanıcıyla etkileşen araçlar da iyi. Kilitli dosyalar olan klasörlerden kaçınırsanız Windows dosya sisteminin tuhaf garipliklerinin çoğunu da gizliyor.
    Biraz sıkı ararsanız istediğiniz işi genelde yaptırabiliyorsunuz. Tavsiye edilebilir.

  • Kariyerim Windows yönetimine yaklaştığı her seferinde o deneyimden gerçekten nefret ettiğimi söyleyen diğer izlenimlere katılıyorum.
    Ama Windows’taki diğer her şeyin aşırı hantal olmasının aksine, PowerShell’in kendisi aslında oldukça iyiydi ve her zaman özenle tasarlanmış hissi veriyordu.
    Linux harika ve iş için günlük ortamım olarak kullanmaya devam edeceğim, ama Bash kullanmak gerçekten berbat. Yine de her yerde, her zaman bulunduğu için herkesin ilk el attığı şey o oluyor; muhtemelen 2100 yılında bile her türlü kusuru olan Bash script’leriyle uğraşıyor olacağız.

  • PowerShell gerçekten Microsoft’un tekelci özgüveninden çıkmış bir ürün gibi.
    Diğer dillerden geçiş yapmayı sağlayacak neredeyse hiç sözdizimsel köprü içermeyen bir dil yapmak cesur bir iş. Komutları, parametreleri ve flag’leri tahmin etmek ya da sezmek mümkün değildi. Microsoft’un hırsları düşünüldüğünde bile, yönetici ve programcı ordularının en azından onlarca yıl boyunca PowerShell ile Bash script’lerini birlikte öğrenip sürdürmek zorunda kalacağını bilmeleri gerekirdi.
    Aşırı uzun sözdizimi komite sunumlarında iyi görünebilir; ama gerçekte sık sık kullanıldığında insan beyninin iyi araştırılmış sınırlarıyla çarpışıyor. Bilgi boyutu ya da gecikme belirli bir eşiği aşınca akış bozuluyor; odaklanma, açık ezber ve tekrar doğrulama gerekiyor. Pratik yapsanız bile düşünceyi gerçeğe dönüştüren sıradan shell büyülerini hızlıca çalıştırmak zor; autocomplete’in çıkmasını bekleyip çok parçalı bir komutun bir sonraki kelimesini kabul edip etmeyeceğinize karar vermek bile sözdizimiyle boğuşmayı gerektiriyor.
    Başlat menüsünde pow.. diye arayınca karşınıza dört harika seçenek çıkıyor: PowerShell, PowerShell ISE ve her birinin normal ve x86 sürümleri. Hangisini seçerseniz seçin yükleme bekletip akışı bozuyor. ISE küçük bir splash screen gösterip başka bir konuma zıplıyor. Başka bir iletişim kutusu, geçen oturumu adsız script dosyasını kaydetmeden kapattığınızı söylüyor; ama zaten beklendiği gibi yeniden açıyor. O zaman neden azarlıyor, anlamıyorum.
    Metin yazıp ya da kopyalayıp herhangi bir kötü amaçlı kodu çalıştırabiliyorsunuz; ama dosyaya kaydedip .ps script’i olarak çalıştırmak isterseniz gülünç bir execution policy süreci başlıyor. Bu, erken dönem Internet Explorer ve Windows’un kötü güvenlik şöhretinden kalan bir travma olabilir.
    Yine de sevmeye çalıştım; ama bir gün script köşeli parantez içeren bir dosya adıyla karşılaştı ve PowerShell o [1], [2] kısımlarını örtük olarak yineleyici benzeri bir şey diye yorumladı: https://stackoverflow.com/questions/21008180/copy-file-with-...
    Bir scripting dilinin temel işlerinden biri dosyalarla uğraşmaktır; dosya adları script yazarının kontrolünde değildir ve Windows’ta geçerli dosya adı alanını bilmesi gerekir. Bu olay, o dile karşı bende kalıcı bir güven sorunu yarattı.
    Azure ekibi Microsoft içinde yeterince güçlüydü herhalde; az find vm, az account show gibi aklı başında ve okunabilir ayrı bir sözdizimi yaptılar.

    • Öyle değil. PowerShell shell’den, Perl’den ve başka birçok dilden ilham aldı; tasarımında bunun izleri görülüyor.
      Diğer tarafın istediği şey ise tutarlılıktı. *NIX bilgisi fiilen kaba ezberle edinilen bir şey. -v çoğunlukla verbose, -h çoğunlukla help olsa da gerçekte hiçbir şeye güvenip bel bağlayamazsınız.

  • Şimdi geriye bakınca, Microsoft’un Windows ve Active Directory, Exchange gibi önemli kurumsal uygulamaların tüm ayarlarını kolayca birleştirilebilir ve programlanabilir bir şekilde yapılandırmanın değerini neden göremediği tuhaf geliyor.
    Alternatif olarak Remote Desktop ile bağlanıp fareyle tıklaya tıklaya dolaşmayı önermiş olmaları fikri saçma. Böyle bir işi otomatikleştirmek, en azından AutoHotkey ve Window Spy deneyimime göre, korkunç derecede zor ve can sıkıcı.

    • Windows ayarlarını kolayca birleştirilebilir ve programlanabilir hale getirmenin sonucunu istemeyen koca bir danışmanlar ve yazılım satıcıları sektörü var.
      Remote Desktop ile bağlanıp fareyle tıklama yöntemi bolca faturalandırılabilir saat üretir.
      Böyle işlerin korkunç derecede zor ve can sıkıcı olmasının alternatif işletim sistemlerinin var olmasının başlıca nedeni olma ihtimalinin yüksek olması ironik.
    • Daha da tuhafı, bu “tıklayıp dolaşma” zihniyetinin Azure’a da girmiş olması.
      Eskiden, adil olmak gerekirse yaklaşık 10 yıl önce, bir ayarı otomatikleştirmenin en iyi yolunun Selenium olduğunu ciddi ciddi öneren bir teknik destek görevlisiyle karşılaşmıştım.

  • 1982’den beri bilgisayar kullanıyorum ama gerçekten hiçbir zaman Windows kullanıcısı olmadım
    1990’ların başında Wintel yükselirken Linux ve 386BSD’nin gelişimini takip ettim; 1990’ların sonunda Win95 ve NT iş masaüstlerine hâkim olduğunda SPARCStation, Linux ve üretimi durdurulmuş NeXT donanımına sığındım. Yüzyıl döndükten sonra ise yeni POSIX uyumlu hâle gelen Mac OS’u benimsedim
    Neredeyse yarım yüzyıl boyunca Microsoft ürünlerinden kaçınmak, bilgisayar kullanım politikamın temeliydi; dikkate değer tek istisna aşağı yukarı Applesoft BASIC’ti
    Ama PowerShell iyi

    • Bilgisayar dünyasında, özellikle de paradigma değiştiren inovasyon akışlarında uzun bir deneyimin var gibi görünüyor
      Ancak ilk paragrafın yarattığı beklentiyi ikinci paragraf bilerek boşa çıkarıyor; PowerShell’i neden “iyi” gördüğünü açıklasan iyi olurdu
    • PowerShell’i Bash’ten daha iyi yapan şeyin ne olduğunu merak ediyorum

  • Uygun bir programlama dili olan C/C++ gibi bir şeyle doğrudan komut satırı araçları yazmak gerektiğinde, geleneksel shell’ler için yapmak ile PowerShell için yapmak arasındaki üretkenlik farkı hafife alınıyor
    Genelde kullanışlı bir CLI aracını, binlerce satırın altında dağınık kod yazmadan yaptığımı hatırlamıyorum. Çoğu zaman pipeline girdisi, isteğe bağlı parametreler, değer alan parametreler, varsayılanlar ve geçersiz kılmalar, dry run modu, çeşitli çıktı biçimi gereksinimleri vb. ile uğraşmak gerekiyor; bu yüzden kodun %90’ı gereksiz yük, yalnızca %10’u gerçek iş oluyor
    PowerShell’de C# modüllerinin temelde yaklaşık 20 satırlık bir overhead’i var; geri kalanın tamamı gerçek iş. Üretkenlik şaşırtıcı derecede yüksek
    Parametre doğrulama, parametre adları için sekmeyle otomatik tamamlama, pipeline girdi ve çıktısı, biçimlendirme, güçlü tipleme, globbing gibi şeylerin hepsi bedavaya geliyor

    • C# kullanmışlığım yok ama katılıyorum
      Bakım ve yönetim işlerinde CLI araçlarından giderek daha fazla derlenen dillere veya yorumlanan dillere kayıyorum