Câu chuyện phát triển PowerShell của Jeffrey Snover

 (corecursive.com)
1 điểm bởi GN⁺ 2024-07-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Jeffrey Snover đã thúc đẩy PowerShell để biến Windows thành một hệ điều hành máy chủ có thể quản trị qua dòng lệnh, và phải vượt qua văn hóa Microsoft vốn thiên về GUI cùng sự kháng cự trong tổ chức
  • Việc port các công cụ UNIX ban đầu không giải quyết được bài toán quản trị máy chủ vì Windows phụ thuộc vào API như Registry, Active Directory, WMI hơn là tệp
  • Sau khi tạo 70 lệnh dựa trên WMI trong WMIC, ông chuyển hướng sang bộ máy sinh lệnh dựa trên metadata כדי giảm nút thắt kiểm thử và chi phí
  • Tiền thân của PowerShell là Monad khởi đầu nhờ làn sóng .NET và Longhorn, nhưng sau khi Longhorn bị reset thì bị đẩy khỏi Windows rồi được hồi sinh nhờ sự hỗ trợ từ nhóm Exchange và tổ chức Windows Server
  • Snover chấp nhận mất cấp bậc và đãi ngộ để tập trung vào PowerShell 1~4, và công cụ này trở thành nền tảng cho tự động hóa quản trị Windows cũng như quá trình chuyển Office lên đám mây

Windows thiên về GUI và bài toán quản trị datacenter

  • PowerShell là công cụ dòng lệnh đã thay đổi cách quản trị hệ thống Windows, nhưng trong nội bộ Microsoft đây không phải dự án được đón nhận tự nhiên ngay từ đầu
  • Văn hóa Microsoft thời đó thiên về GUI, đến mức có giai thoại rằng Bill Gates từng nói ông sẽ nhìn thấy command.exe lần cuối, cho thấy giao diện dòng lệnh bị xem là thứ lỗi thời
  • Điểm xuất phát khi Snover gia nhập Microsoft là nhận thức rằng cần phải biến hệ điều hành dựa trên Windows NT thành thứ phù hợp với thị trường datacenter và enterprise
    • Mục tiêu là cạnh tranh với các nhà cung cấp UNIX như Sun, IBM, HP
    • Intel và hệ sinh thái phần cứng mở có lợi thế về chi phí, nhưng phần mềm quản trị máy chủ thì chưa đủ tốt

Mô hình quản trị viên giúp giảm phụ thuộc vào nhà tích hợp hệ thống

  • Việc quản trị Windows Server đòi hỏi phải cấu hình nhiều máy chủ bằng thao tác nhấp chuột, và cấu hình cần thiết lại khác nhau ở từng doanh nghiệp nên mức độ phụ thuộc vào nhà tích hợp hệ thống có thể tăng cao
  • Snover cho rằng nếu chi phí tích hợp tăng mạnh thì lợi thế giá của Windows sẽ biến mất
    • Ông nêu ví dụ cấu trúc chi phí gồm phần cứng 10, phần mềm 2, nhà tích hợp hệ thống 40
    • Việc quan hệ và giá trị với khách hàng bị chuyển sang phía nhà tích hợp cũng là một vấn đề
  • Phương án thay thế là mô hình quản trị viên kiểu lập trình viên của UNIX
    • Cách làm là kết hợp các công cụ nhỏ để giải quyết bài toán riêng và tự động hóa
    • Windows cũng cần một tầng quản trị viên chuyên nghiệp biết dùng script và tự động hóa, thay vì chỉ có “quản trị viên bấm nút Next”

Vì sao việc port công cụ UNIX không phù hợp

  • Giải pháp ban đầu là dùng Windows Services for Unix để đưa UNIX shell và các công cụ như AWK/GREP/SED lên Windows
  • Nhưng cấu trúc quản trị của Windows khác với UNIX
    • UNIX là hệ điều hành xoay quanh tệp, nên có thể xử lý nhiều tác vụ quản trị bằng cách thao tác với tệp và khởi động lại tiến trình
    • Windows là cấu trúc mà chức năng nằm sau các API như Registry, Active Directory, WMI
    • AWK không khớp trực tiếp với Registry, SED không khớp với Active Directory, GREP cũng không khớp trực tiếp với WMI
  • WMI có tiềm năng cho công việc quản trị nhưng chưa được dùng rộng rãi, nên nhóm của Snover đã định tạo công cụ dòng lệnh để xử lý các đối tượng WMI

WMIC và bộ máy dựa trên metadata

  • Trong giai đoạn Windows XP, họ phải tạo giao diện dòng lệnh dựa trên WMI trong điều kiện chỉ có 10 tuần cửa sổ coding
  • Dù tận dụng kỹ sư hợp đồng để triển khai 70 tác vụ, con số đó vẫn quá ít so với phạm vi cần thiết để quản trị toàn bộ Windows Server
  • Bên trong Microsoft, nếu tổ chức kiểm thử không phê duyệt thì tính năng sẽ không được phát hành, và số lệnh càng tăng thì nút thắt kiểm thử cũng càng lớn
  • Snover thúc đẩy cách làm coi từng lệnh là metadata thay vì code riêng lẻ, giống quan hệ giữa HTML và trình duyệt, để chỉ cần kiểm thử bộ máy chung
    • Bộ máy sẽ sinh lệnh, còn cấu hình của từng lệnh được biểu diễn bằng metadata ở dạng như XML
    • Ông đã viết metadata trong kỳ nghỉ Giáng sinh để tạo ra 72 lệnh
    • Ông nhớ lại rằng 70 lệnh cũ tiêu tốn khoảng 4 triệu USD, còn bộ máy chỉ tốn khoảng 60.000 USD
  • Khi thêm các tính năng như lọc và định dạng vào bộ máy, mọi lệnh đều được cải thiện cùng lúc, và đây trở thành dấu hiệu báo trước quan trọng của kiến trúc PowerShell

Longhorn, .NET, Monad

  • Bill Gates thấy người dùng Windows 98 không chuyển sang XP tốt như kỳ vọng nên muốn biến Longhorn thành bước ngoặt mới kiểu Windows 95
    • Longhorn dự kiến bao gồm mô hình phát triển dựa trên .NET, WPF, WCF và mô hình lưu trữ mới
  • Snover nhận định .NET có thể là phương tiện để mở rộng phạm vi quản trị của Windows
    • Việc viết WMI provider không tạo được đủ động lực, nhưng Bill Gates lại thúc đẩy rất mạnh việc áp dụng .NET
    • Ông cho rằng đặt tiện ích quản trị lên trên .NET có thể mang lại độ bao phủ rộng hơn
  • Khi một tổ chức khác định port K-shell để làm shell, Snover đã giải thích rằng có cách tiếp cận tốt hơn nhưng không thuyết phục được họ
  • Ông tự nhốt mình trong phòng và tạo ra một prototype khoảng 10.000 dòng, trong đó đã có các nguyên tắc kiến trúc cốt lõi của PowerShell
    • Sau buổi demo, nhóm đó chấp nhận ý tưởng và Snover nghĩ đây có thể là ý tưởng hay nhất đời mình
    • Để tham gia dự án này, ông đã từ bỏ vai trò chief architect của một sản phẩm và dịch vụ quy mô hàng trăm đến hàng nghìn người, về thực chất là chấp nhận bị giáng cấp

Monad Manifesto và thuyết phục các nhóm

  • Nhóm mới đặt tên dự án là Monad, và vì thiếu nhân lực nên một phần công việc được thuê ngoài sang Ấn Độ
  • Snover đã viết Monad Manifesto để thống nhất tầm nhìn dự án và con đường đi đến thành công
    • Tài liệu này sắp xếp lại vấn đề, cách tiếp cận cũ, cách tiếp cận mới, giá trị và điểm khác biệt
    • Đồng thời làm rõ giá trị mang lại cho từng nhóm liên quan như quản trị viên, provider, đội phát triển
  • Mỗi nhóm trong Microsoft đều có rất nhiều việc phải làm; việc không tạo giao diện dòng lệnh cũng không khiến ai bị sa thải, còn có làm thì cũng không dẫn tới thăng tiến
  • Đề xuất của Monad là mỗi nhóm sản phẩm chỉ cần viết code thao tác với đối tượng của riêng họ, còn phần còn lại do PowerShell cung cấp
    • Các tính năng như định dạng, sắp xếp, lọc, parser, thực thi từ xa, nâng quyền đều do phía PowerShell cung cấp
    • Mỗi nhóm chỉ cần cho biết cách thao tác với object trong miền của mình
  • Nhóm Active Directory đã đầu tư vài tuần để tạo một số cmdlet, và khi phản ứng từ cộng đồng người dùng rất mạnh thì họ tiếp tục làm thêm

Trở lại Windows sau đợt reset Longhorn

  • Trong Longhorn, việc đưa .NET vào đã bị đẩy quá mức khiến vấn đề ngày càng lớn
    • Ví dụ như hộp thoại Save As của Notepad phải mất 1 phút 30 giây mới hiện ra vì dùng hộp thoại dùng chung dựa trên .NET/WCF, còn working set thì tăng từ 15KB lên 15MB
    • Cũng có hồi tưởng rằng nightly build đã không hoạt động trong khoảng 7 tháng
  • Tổ chức Windows đã reset và loại mã .NET ra khỏi Windows, PowerShell vì thế cũng bị đẩy ra khỏi Windows
  • Sau đó PowerShell liên tục chịu áp lực bị hủy vì vừa là giao diện dòng lệnh vừa dựa trên .NET
    • Bill Gates hiểu giá trị của nó, nhưng điều đó không giúp được nhiều trong các cuộc phòng thủ hằng ngày
    • Người phụ trách Windows Server đã hỗ trợ vào những thời điểm quan trọng
    • Nhóm Exchange đóng vai trò ngăn dự án bị hủy khi nhấn mạnh rằng họ có một “mảng kinh doanh trị giá hàng tỷ USD” phụ thuộc vào PowerShell
  • Các yêu cầu WinArch để đưa .NET vào Windows rất khắt khe, nhưng nhóm PowerShell đã chuẩn bị để đáp ứng mọi điều kiện
  • Khi người phụ trách Windows yêu cầu rút đề nghị, program manager đã yêu cầu một sự từ chối chính thức, và kết quả là một quy trình review được mở ra
    • Tổ chức Windows Server nắm quyền quyết định việc này và kết luận rằng PowerShell đáp ứng yêu cầu, nên nó được đưa trở lại Windows

PowerShell 1~4 và tác động thực tế

  • PowerShell 1 được phát hành như một phần của Windows Vista
  • Sau khi phát hành, Snover được khuyên nên chuyển sang việc khác và được cảnh báo về bất lợi trong sự nghiệp, nhưng ông vẫn tập trung vào cùng một tầm nhìn cho đến PowerShell 2, 3, 4
    • Ông nhớ lại rằng phiên bản 1 đã đạt được một phần mục tiêu, phiên bản 2 và 3 bổ sung các tính năng còn thiếu, còn đến phiên bản 4 thì tầm nhìn gần như hoàn tất
  • PowerShell đã giúp các quản trị viên Windows viết script và tự động hóa các tác vụ phức tạp
    • Từ đó hình thành các nhóm người dùng, hoạt động hỏi đáp trực tuyến, chia sẻ script và các bài trình bày hội nghị
    • Một số quản trị viên nhờ kinh nghiệm PowerShell mà trở thành diễn giả chuyên nghiệp
  • Khoảng 5 năm sau, Snover trở thành Distinguished Engineer, rồi sau đó là Technical Fellow
  • Người phụ trách Office nói rằng nếu không có PowerShell thì quá trình chuyển Office lên cloud sẽ rất khó, và việc Office lên cloud cũng ảnh hưởng đến quá trình Azure chuyển sang cloud
    • Trước đây việc provisioning server là thao tác nhấp chuột nên rất khó lặp lại và chỉnh sửa
    • Nhờ có script, họ mới có thể mở rộng quy mô, và khi có vấn đề thì chỉ cần sửa script để ứng phó

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-07-05
Ý kiến trên Hacker News

  • Nhìn từ góc độ người dẫn chương trình, PowerShell đã vấp phải sự phản đối dữ dội trong nội bộ Microsoft, và người tạo ra nó là Jeffrey Snover thậm chí còn bị giáng chức vì cố thúc đẩy nó
    Ban đầu Jeffrey được tuyển vào để giúp Microsoft học cách cạnh tranh trong lĩnh vực trung tâm dữ liệu, nhưng văn hóa khi đó bị trói quá chặt vào thế giới quan xoay quanh máy tính cá nhân, nên ông gặp phản kháng ở từng bước
    Một điểm thú vị nữa là PowerShell ra đời vì Windows không dựa trên tệp. Mục tiêu của Jeffrey là quản trị máy chủ, nhưng trên Windows không thể quản lý chỉ bằng cách chỉnh sửa các tệp cấu hình; phải gọi nhiều API để trao đổi dữ liệu có cấu trúc, nên một mô hình đối tượng phong phú về cơ bản là cách duy nhất
    Bản chép lời được tạo theo quy trình chép máy chuyên nghiệp, rồi qua Descript, GPT-4 để chỉnh dấu câu, và tự rà soát lại, nhưng chất lượng có thể không cao như mong đợi

    • Nếu đội MS-PWSH thấy điều này, tôi mong họ thêm các tính năng GUI cơ bản để không phải tự viết nhiều mã .NET
      Lý do tôi thích PowerShell là vì nó là một ngôn ngữ động đơn giản và có thể nối các lệnh dễ dùng với nhau, nên sẽ rất hay nếu có một bộ cmdlet mới để tạo giao diện người dùng đơn giản và biểu đồ
      Ví dụ, một tính năng như Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" có vẻ là thứ Microsoft có thể dễ dàng đưa vào sản phẩm, và có thể loại bỏ cả một trang mã boilerplate mà tôi không hiểu rõ
      Chắc chắn có hàng triệu người biết lập trình cơ bản nhưng các công cụ như Java hay C# không phù hợp với công việc của họ. Python thường khá phù hợp, nhưng tôi mong Microsoft tạo thêm thứ gì đó không chỉ dành cho quản trị viên máy chủ hay nhân viên IT, mà cả người dùng nghiệp vụ thông thường cũng dùng được
      Nếu đầu tư thêm để PowerShell không chậm trong các tác vụ như phân tích tệp, đồng thời bổ sung các tính năng đã nói ở trên hoặc cả cmdlet cho thống kê và khoa học, nó có thể trở thành một công cụ khá tuyệt vời để một nhà phân tích nghiệp vụ thông thường nhanh chóng tạo phần mềm cải thiện công việc hoặc nguyên mẫu để chuyển cho đội phát triển
      Có vẻ Microsoft xem các lựa chọn là ba thứ: nhà phát triển phần mềm chính thức dùng C#, công việc IT dùng PowerShell, và Excel cho người dùng nghiệp vụ. Excel tuyệt vời ở nhiều mặt nhưng khá hạn chế, còn VBA+Excel thuộc nhóm hệ sinh thái hạn chế nhất mà tôi từng dùng. Các ngôn ngữ bên thứ ba như Python, R là lựa chọn thứ tư, nhưng tôi mong Microsoft dành nhiều thời gian hơn cho mảng này
    • Nhìn các MVP trên GitHub phàn nàn rằng khoản đầu tư bổ sung Microsoft từng hứa đã không thành hiện thực, các thay đổi không được đưa vào, và những tính năng tốt bị bỏ mặc, có vẻ đây không còn là ưu tiên của MSFT nữa
      Tôi từng thích PowerShell, kể cả những điểm kỳ quặc của nó, nhưng giờ đã rời đi
    • Tôi tò mò vì sao họ lại làm mới từ đầu thay vì dùng Python hay một công cụ sẵn có tương tự
    • Tôi đã thử đọc bản chép lời nhưng không đọc hết được, và thấy hơi khó đọc
      Trong lúc đọc tôi đoán nó được tạo bằng máy, nhưng khó nói cụ thể vì sao; có vẻ cần biên tập thêm một chút để dễ đọc hơn
      Dù vậy, có bản chép lời vẫn tốt hơn rất nhiều so với không có gì

  • Là một lập trình viên đã dùng Bash lâu năm, khi PowerShell ra mắt tôi đã thật sự rất kỳ vọng
    Tôi nghĩ cuối cùng trên Windows cũng sẽ có một shell tuyệt vời cho phát triển, nhưng về sau tôi vẫn không thật sự nắm được PowerShell, và trên Windows vẫn tiếp tục dùng Bash quen thuộc
    Tôi tò mò các lập trình viên thành thạo cả hai shell so sánh chúng thế nào. Muốn biết PowerShell có thực sự hiện thực hóa lời hứa là một shell hiệu quả và hiện đại hơn không, hay chỉ được dùng vì nó được cài sẵn và tốt hơn CMD

    • Tôi đã dùng Bash rất nhiều và cũng đọc vài cuốn sách, nhưng tin chắc rằng không nên viết script Bash phức tạp
      Nếu vượt khoảng 50 dòng thì tôi xem đó là code smell, và đã lưu trang này để dùng khi cần thuyết phục ai đó: http://mywiki.wooledge.org/BashPitfalls
      Gần đây dùng thử PowerShell, tôi thấy việc lệnh trả về đối tượng thay vì văn bản, nên không cần cố xử lý text, khiến nó dễ dùng hơn nhiều với tư cách vừa là ngôn ngữ script vừa là ngôn ngữ dòng lệnh
      Việc có một cách chính thức để xử lý phân tích tham số cũng rất tuyệt. Mọi thứ thống nhất, và trong cửa sổ dòng lệnh thực tế có thể tự động hoàn thành mọi tùy chọn, điều mà Bash khó mơ tới, nên năng suất tăng rất nhiều
      Tuy nhiên ép kiểu cũng tạo ra những lỗi mới mà Bash không có. Hiện tôi thích PWSH hơn, nhưng ít nhiều vẫn không thích cả hai, và đang chờ bước tiến hóa tự nhiên tiếp theo
    • PowerShell dài dòng hơn Bash, và có những điểm kỳ lạ như tự động bung mảng có 0 hoặc 1 phần tử thành scalar vào những lúc không ngờ, nhưng nó năng suất hơn và dễ đọc hơn
      Hướng đối tượng khá hữu ích khi xây dựng pipeline
      Ví dụ, để đệ quy trong một thư mục, nhóm theo kích thước tệp nhằm tìm ứng viên trùng lặp, có thể viết Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count
      Không cần nhớ câu thần chú file khó hiểu, cũng không cần parse output dạng text. Bạn nhận các đối tượng thật có thuộc tính, và tính năng tự động hoàn thành bằng tab có thể thấy cấu trúc đó
      Nếu cần parse JSON, không cần jq, chỉ cần xử lý ngay bằng Get-Content -Raw whatever.json | ConvertFrom-Json. Muốn đổi XML sang CSV thì dùng ConvertFrom-Xml hoặc Select-Xml, thực hiện các thao tác cần thiết rồi dùng ConvertTo-Csv
      Nếu Get-ChildItem quá dài thì dùng gci, dir, ls; nếu Where-Object dài thì dùng where hoặc ?. Mặc định cũng không phân biệt chữ hoa chữ thường
    • Tôi bắt đầu sự nghiệp với X terminal trên một “hộp pizza” SunOS, đã viết hàng nghìn script, trong đó khá nhiều cái dài hàng nghìn dòng
      Vài năm trước tôi phải viết bằng PowerShell một hệ thống truyền dữ liệu phức tạp, chạy không người giám sát và vững chắc; trải nghiệm đó tốt đến mức tôi đã đổi toàn bộ shell trên macOS và Linux sang PWSH
      Điều tôi thích nhất là sức mạnh của việc truyền đối tượng qua pipeline. Ở filter đầu tiên, sau khi trích xuất và thao tác một số thuộc tính của đối tượng, các filter phía sau trong pipeline vẫn tiếp tục truy cập được những thuộc tính khác cũng như các thuộc tính đối tượng do filter đầu tạo ra
      Tính nhất quán của lệnh, xử lý lỗi và thuộc tính đối tượng cũng rất tốt
      Sau đó tính chất công việc thay đổi, trí nhớ cơ bắp cũ sống lại và tôi chuyển toàn bộ shell về Bash. Khi làm việc và suy nghĩ nhiều trong không gian đó, PWSH là một shell tự nhiên; nhưng khi đã rời khỏi nó, việc suy nghĩ theo PWSH còn khó hơn quay lại Bash
      Thỉnh thoảng tôi vẫn nhớ nó. Trong lĩnh vực shell, không có gì tiệm cận được đến mức đó, và ít nhất tôi không thấy lựa chọn thay thế nào đủ gần để biện minh cho công sức chuyển đổi
    • Tôi không phải chuyên gia về cả hai nhưng đã dùng khá nhiều, và cảm thấy PowerShell trở nên kinh khủng vì một số cạm bẫy
      Thứ nhất là việc nó cố trở thành một ngôn ngữ .NET. Tôi không biết vì sao lời hứa của .NET về một runtime với nhiều ngôn ngữ lại héo úa trong .NET, trong khi phía Java vẫn phát triển mạnh mà không cần lời hứa như vậy, nhưng nếu định viết mã .NET thì tôi nghĩ dùng C# sẽ tốt hơn
      Thứ hai, nó không nắm chắc các nền tảng cơ bản của shell. Chi tiết giờ tôi đã chôn vào quá khứ nên không nhớ nữa, nhưng xử lý redirection bị hỏng, và những việc tầm thường trong Bash gần như bất khả thi trong PowerShell. Tôi có cảm giác các nhà phát triển quá hào hứng tạo ra thứ mới và mạnh đến mức phớt lờ những gì Bash và các shell khác đã làm tốt
      Thứ ba, nó ám ảnh với việc yêu cầu mọi tên theo dạng Verb-Object. Đây là chuyện chủ quan và chắc có người bênh vực, nhưng tôi cho rằng nó làm script xấu đi, gõ cũng gượng gạo, và cũng không thực sự cải thiện khả năng khám phá hay ghi nhớ
    • Tôi không thích PowerShell vì có vô số điểm gây bất ngờ theo cách quá khác Bash
      Việc phải dùng phím mũi tên phải thay vì tab cũng gây rối, và việc thiếu các lệnh quen thuộc cùng quy tắc đặt tên mạnh cũng bất tiện
      Dù vậy, nếu biết rõ thì PowerShell có vẻ năng lực hơn Bash. Nó có hệ thống kiểu tốt hơn và dễ xử lý tham số hơn, trong khi các giá trị của Bash gần như chỉ là chuỗi không có hình dạng
      https://github.com/bionicles/tree_plus/blob/main/tests/more_... là một phiên bản hơi cũ tôi dùng khi thiết lập môi trường test trên máy Windows, và phần nào cho thấy có thể làm được những gì

  • Khi tự dùng PowerShell thì tôi không thấy quá khủng khiếp, nhưng vẫn không hiểu vì sao mảng có độ dài 1 lại bị bóc khỏi mảng và biến thành kiểu bên trong
    Vì chuyện này, lần nào cũng phải để ý xem mảng có thể có bao nhiêu phần tử, và thay vì xử lý theo cách tổng quát thì mỗi lần sửa lại phải kiểm tra, gây ra vô số bug. Tôi tò mò không biết có ai biết vì sao lại làm như vậy không

    • Lý do phần xử lý quanh mảng lỏng lẻo là vì API xuất của cmdlet cũng lỏng lẻo với mảng
      Chỉ có một hàm tên WriteObject ghi giá trị được đưa vào thành output của cmdlet; gọi một lần thì đó là output. Gọi nhiều lần thì shell buộc phải gom tất cả các giá trị đó thành một mảng để làm output
      Vì vậy nếu trong một lần chạy cmdlet chỉ gọi WriteObject một lần, còn lần chạy khác gọi hai lần, thì ở trường hợp đầu shell không thể có thông tin rằng output đơn lẻ đó cũng đáng ra phải được bọc trong mảng. Nhưng nếu lúc nào cũng bọc output của cmdlet trong mảng thì lại gây vướng cho các cmdlet về mặt ngữ nghĩa chỉ có một kết quả, như Get-Date
      Vì lý do nào đó, có vẻ họ không muốn làm API phức tạp hơn để bản thân cmdlet có thể biểu đạt rằng về mặt ngữ nghĩa output là đơn hay nhiều, bất kể số lần gọi WriteObject thực tế. API như vậy không thể là thuộc tính tĩnh của cmdlet, vì output có thể thay đổi rất nhiều tùy theo tham số; và vì cũng phải hoạt động với mảng rỗng nên một overload WriteObject kiểu (Object, bool iMightWriteMoreValues) cũng khó ổn. Có lẽ sẽ cần một hàm riêng kiểu IWillWriteMultipleValues()
      Ở đây cũng có giải thích: https://news.ycombinator.com/item?id=40874873
    • Cái này thật sự rất khó chịu. Tôi bắt đầu dùng comma hack, thêm dấu phẩy ở trước để ép thành mảng
      $Ary = @(, "value")
      Khi tạo mảng, nhất là mảng lớn, cách gán một vòng lặp for cho mảng cũng khá hay vì hiệu năng tốt hơn +=. Không trực quan lắm như một cách điền dữ liệu vào mảng, nhưng rõ ràng là hữu ích
      $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
    • Nghe như một ví dụ điển hình về việc phần mềm cố trở nên quá thông minh rồi thất bại
      Nhà phát triển phần mềm luôn phải cảnh giác trước cám dỗ muốn làm phần mềm của mình quá thông minh
    • Cảm giác như một tính năng mới làm nửa vời
      Nửa còn thiếu lẽ ra là khả năng tự động chuyển một giá trị đơn thành mảng độ dài 1 khi phía nhận đang kỳ vọng một mảng
    • Có vẻ ngôn ngữ ngách nào rồi cũng có những điểm dị thường điên rồ kiểu này
      Dù đã có những thứ như Lua, thay vì dùng nguyên xi hoặc chỉnh sửa một chút để có một ngôn ngữ đơn giản, nhỏ gọn, thanh nhã và nhất quán, người ta lại tái phát minh bánh xe nhưng còn không làm cho nó tròn được — đúng bi kịch kiểu Sisyphus

  • Trừ khi cần tương tác với các hệ thống con của Windows nên phải dùng một lệnh PowerShell cụ thể, tôi thường nghĩ: “sao mình không dùng Python nhỉ?”
    Nó quá dài dòng và chậm cho 90% việc tôi sẽ làm bằng Bash, và cũng vậy với những việc mà ở một đời khác tôi đã dùng Perl để làm
    Tôi thường thắc mắc vì sao Microsoft không xây dựng nó trên Python, Node hay thứ gì tương tự. Tôi không nhớ PowerShell ra mắt lần đầu khi nào, nên cũng không chắc vào thời điểm đó cái gì mới là lý tưởng

    • REPL mặc định của Python thật sự rất tệ
      Ngoài ra nó không được thiết kế cho các tác vụ console mà PowerShell làm tốt. Những việc đáng ra chỉ cần nhận nội dung file rồi chuyển sang lệnh khác thì lại phải tự xử lý kiểu quản lý file handle
      PowerShell hay ở chỗ nó là một dao đa năng Thụy Sĩ: REPL tốt với tự động hoàn thành, không có hành vi whitespace kỳ quặc, readline[0], và nếu cần thì làm được mọi thứ .NET có thể làm
      Hơn nữa nó hướng đối tượng, nên thay vì phải tìm cách phân tích output dạng văn bản của một tiện ích cũ kỹ bằng một tiện ích cũ kỹ khác, bạn có thể tập trung vào việc thật sự cần làm
      0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
    • Ban đầu nó được dựa lỏng lẻo trên Perl và Korn shell
      Trong ấn bản đầu của “Powershell in Action” của Bruce Payette có một đoạn giải thích bên lề rằng PowerShell trông giống Perl vì dùng ký hiệu @, biến mặc định $_, và toán tử gọi hàm &. Thực tế, có một thời nó dùng Perl làm ngôn ngữ gốc, và các yếu tố này đến từ giai đoạn đó. Về sau cú pháp được đổi để phù hợp hơn với C#, nhưng các yếu tố này hoạt động tốt nên được giữ lại; theo cách nói của Perl, chúng đóng góp đáng kể vào “whipupitude quotient” của ngôn ngữ
      Ngoài ra, ngôn ngữ lõi của PowerShell dựa trên cú pháp POSIX 1003.2 của Korn shell; ban đầu các khái niệm nâng cao như bảng băm được mượn từ idiom của Perl, nhưng khi dự án tiến triển, việc chỉnh cú pháp PowerShell cho khớp với C# trở nên rõ ràng là phù hợp hơn
    • PowerShell ra đời trước Node 3 năm
      Việc nó không dựa trên thứ khác có lẽ phần lớn là vì Microsoft kiểm soát .NET
      Tôi không nghĩ lý do chậm là do .NET, mà có lẽ là vấn đề thiết kế hoặc thiếu đầu tư vào hiệu năng
      Tuy vậy còn tùy bạn dùng phiên bản PS nào. Theo trí nhớ thì các phiên bản mới khá nhanh

  • Ở nơi làm việc, tôi đã được “ban phước” phải xử lý một codebase stored procedure SQL Server hơn 20 năm tuổi
    Đó là khoảng 300 nghìn dòng mã cốt lõi nghiệp vụ đã qua kiểu monkey testing, nhưng không có quản lý mã nguồn, cũng chưa từng được tuning hiệu năng đúng nghĩa; SQL được chỉnh sửa/chạy trong SSMS rồi triển khai ra môi trường, và tất nhiên cũng không có kiểm thử tự động
    Công ty lấy Windows làm trung tâm, phát triển trên Mac, còn GitHub Actions thì dùng Linux
    Chúng tôi đã chọn các công cụ như PowerShell Core, sqlcmd, docker để chạy instance Windows SQL Server, RedGate SQL Compare để trích xuất schema và mã từ các server legacy hiện có, tSQLt cho unit test, TSqlLint để kiểm tra tuân thủ mã, SQLFluff để kiểm tra style, và Flyway để triển khai
    Khi Windows phải là một trong các nền tảng, tôi nhanh chóng nhận ra PowerShell Core là shell scripting đa nền tảng có khả năng tương tác tốt nhất
    Viết code thì không vui lắm. Regex engine đến từ .NET và có vấn đề backtracking nghiêm trọng, hành vi của mảng cũng kỳ lạ. Việc khởi chạy executable theo cách mình muốn và bắt các output stream cũng thất thường, nên đôi khi phải chạy process, redirect output ra file tạm, rồi đọc file đó sau khi child process kết thúc. Ngay cả việc pipe stdout của child process vào một biến chuỗi cũng phiền phức hơn mức cần thiết
    Nhưng PowerShell Core chạy nhanh. Nếu Microsoft làm tốt một thứ thì đó là tối ưu vi mô. Các công cụ tương tác với người dùng, như bộ chọn danh sách bằng ASCII art hay trình tạo prompt nhập liệu đơn giản, cũng tốt. Nếu tránh các thư mục có file bị khóa thì phần lớn những điểm kỳ quặc của hệ thống file Windows cũng được che đi
    Chịu khó tìm kiếm thì nhìn chung có thể làm được việc mình muốn. Đáng để khuyến nghị

  • Tôi đồng ý với những cảm nhận khác rằng mỗi khi sự nghiệp nghiêng gần hơn về quản trị Windows thì trải nghiệm đó thật sự rất đáng ghét
    Nhưng khác với mọi thứ khác của Windows vốn cực kỳ thô kệch, bản thân PowerShell thực ra khá tuyệt, và luôn cho cảm giác được thiết kế cẩn trọng
    Linux rất tuyệt và tôi vẫn sẽ dùng nó làm môi trường hằng ngày cho công việc, nhưng dùng Bash thì thật sự kinh khủng. Dù vậy, vì nó luôn có ở khắp nơi nên ai cũng đụng đến nó đầu tiên, và có lẽ đến năm 2100 chúng ta vẫn sẽ tiếp tục xử lý các script Bash đầy khuyết điểm

  • PowerShell thật sự có cảm giác là một sản phẩm sinh ra từ sự tự tin độc quyền của Microsoft
    Tạo ra một ngôn ngữ gần như không có điểm nối cú pháp nào để người từ ngôn ngữ khác chuyển sang là một việc táo bạo. Không thể đoán hay suy luận được lệnh, tham số, flag. Ngay cả xét tham vọng của Microsoft, họ lẽ ra phải biết rằng đội ngũ quản trị viên và lập trình viên sẽ phải học và duy trì PowerShell song song với script Bash trong ít nhất vài chục năm
    Cú pháp cực kỳ dài dòng có thể trông hay trong một bài thuyết trình trước hội đồng, nhưng khi phải đụng tới thường xuyên trong thực tế, nó va vào những giới hạn đã được nghiên cứu kỹ của não người. Khi kích thước thông tin hoặc độ trễ vượt quá một mức nào đó, dòng tập trung bị phá vỡ, và người dùng phải tập trung, ghi nhớ tường minh rồi kiểm tra lại. Dù luyện tập, vẫn khó thực hiện nhanh những “thần chú” shell phổ biến để biến ý nghĩ thành hiện thực; chỉ riêng việc chờ autocomplete hiện ra rồi quyết định có chấp nhận từ tiếp theo trong một lệnh nhiều phần hay không cũng đã khiến ta phải vật lộn với cú pháp
    Nếu tìm pow.. trong Start menu, bạn sẽ thấy bốn lựa chọn tuyệt đẹp: PowerShell, PowerShell ISE, cùng bản thường và bản x86 của từng cái. Chọn bên nào cũng phải chờ load, làm đứt mạch. ISE hiện một splash screen nhỏ rồi nhảy sang vị trí khác. Một hộp thoại khác báo rằng phiên trước đã bị đóng mà chưa lưu một file script không tên, nhưng dù sao nó vẫn mở lại đúng như dự kiến. Vậy thì không hiểu trách móc để làm gì
    Bạn có thể nhập hoặc copy văn bản để chạy bất kỳ mã độc nào, nhưng nếu lưu thành file rồi chạy dưới dạng script .ps thì một quy trình execution policy nực cười sẽ bắt đầu. Có lẽ đó là chấn thương từ tiếng xấu bảo mật của Internet Explorer đời đầu và Windows
    Dù vậy tôi vẫn đã cố yêu nó, cho đến một ngày script gặp tên file có dấu ngoặc vuông, và PowerShell ngầm diễn giải [1], [2] đó như kiểu iterator: https://stackoverflow.com/questions/21008180/copy-file-with-...
    Một trong những công việc cốt lõi của ngôn ngữ scripting là xử lý file, mà tên file thì người viết script không kiểm soát được, và nó phải hiểu không gian tên file hợp lệ trên Windows. Chuyện này khiến tôi có vấn đề niềm tin lâu dài với ngôn ngữ đó
    Có vẻ team Azure đủ thế lực trong Microsoft nên đã tự tạo ra cú pháp tỉnh táo và dễ đọc như az find vm, az account show

    • Không phải vậy. PowerShell lấy cảm hứng từ shell, Perl và nhiều ngôn ngữ khác, và dấu vết đó có thể thấy trong thiết kế
      Mặt khác, điều họ muốn là tính nhất quán. Kiến thức *NIX thực chất thường có được bằng cách học vẹt một cách thô bạo. -v nhìn chung là verbose và -h nhìn chung là help, nhưng thực tế thì không thể tin và dựa vào bất cứ điều gì

  • Nhìn lại bây giờ, thật lạ là Microsoft đã không thấy giá trị của việc cấu hình mọi thiết lập của Windows và các ứng dụng enterprise quan trọng như Active Directory, Exchange theo cách dễ kết hợp và có thể lập trình
    Ý nghĩ rằng họ đề xuất phương án thay thế là kết nối bằng Remote Desktop rồi nhấp chuột qua lại thật vô lý. Tự động hóa những thao tác đó, ít nhất theo kinh nghiệm của tôi với AutoHotkey và Window Spy, là cực kỳ khó và phiền phức

    • Có cả một ngành gồm consultant và software vendor không muốn kết quả là cấu hình Windows trở nên dễ kết hợp và có thể lập trình
      Cách kết nối bằng Remote Desktop rồi nhấp chuột tạo ra rất nhiều giờ có thể tính phí
      Thật mỉa mai khi việc đó cực kỳ khó và phiền phức có lẽ là một trong những lý do chính khiến các hệ điều hành thay thế tồn tại
    • Điều kỳ lạ hơn là tư duy “nhấp chuột đi lòng vòng” đó cũng đã len vào Azure
      Trước đây, nói cho công bằng là khoảng 10 năm trước, tôi từng nhận được đề xuất nghiêm túc từ một nhân viên hỗ trợ kỹ thuật rằng cách tốt nhất để tự động hóa một thiết lập nào đó là dùng Selenium

  • Tôi đã dùng máy tính từ năm 1982, nhưng thực sự chưa từng là người dùng Windows dù chỉ một lần
    Khi Wintel trỗi dậy vào đầu thập niên 1990, tôi theo dõi sự phát triển của Linux và 386BSD; khi Win95 và NT thống trị desktop doanh nghiệp vào cuối thập niên 1990, tôi lánh sang SPARCStation, Linux và phần cứng NeXT đã bị ngừng sản xuất. Sau khi bước sang thế kỷ mới, tôi đón nhận Mac OS khi nó mới tuân thủ POSIX
    Trong gần nửa thế kỷ, việc tránh các sản phẩm Microsoft là cốt lõi trong chính sách sử dụng máy tính của tôi, với ngoại lệ đáng chú ý chỉ khoảng Applesoft BASIC
    Thế nhưng PowerShell thì tốt

    • Có vẻ như người này có kinh nghiệm lâu năm về điện toán, đặc biệt là những làn sóng đổi mới đã thay đổi mô hình
      Tuy nhiên, đoạn đầu tạo ra một kỳ vọng mà đoạn thứ hai lại cố tình đi chệch khỏi đó; tôi muốn họ giải thích vì sao họ cho rằng PowerShell “tốt”
    • Tôi tò mò điều gì khiến PowerShell tốt hơn Bash

  • Khi cần tự viết công cụ dòng lệnh bằng một ngôn ngữ lập trình phù hợp như C/C++, sự khác biệt về năng suất giữa việc viết cho shell truyền thống và viết cho PowerShell thường bị đánh giá thấp
    Nói chung, tôi chưa từng tạo ra một công cụ CLI hữu ích mà không cần đến vài nghìn dòng mã lộn xộn trở xuống. Thường phải xử lý đầu vào pipeline, tham số tùy chọn, tham số có giá trị, giá trị mặc định và ghi đè, chế độ dry run, yêu cầu về nhiều định dạng đầu ra, v.v.; thành ra 90% là phần thừa và chỉ 10% là hành vi thực sự
    Trong PowerShell, một mô-đun C# về cơ bản chỉ có khoảng 20 dòng overhead, còn lại toàn bộ là hành vi thực sự. Năng suất đáng kinh ngạc
    Bạn có được miễn phí mọi thứ: kiểm tra hợp lệ tham số, tự động hoàn thành bằng phím tab cho tên tham số, đầu vào và đầu ra pipeline, định dạng, kiểu mạnh, globbing, v.v.

    • Tôi chưa từng dùng C#, nhưng đồng ý
      Với các công việc bảo trì và quản trị, tôi ngày càng chuyển từ công cụ CLI sang các ngôn ngữ biên dịch hoặc thông dịch