GitHub CLI 1.0 sürümü yayınlandı!
GitHub arayüzü üzerinde yapabildiğimiz hemen her şeyi komut satırı ekranınızdan (terminal) yapabilmenize olanak sağlayan araç 1.0 sürümü itibariyle beta programından çıkmış ve kararlı (stable) haliyle indirmenizi bekliyor.

Bu araçla birlikte gelen bazı özellikler:
* gh repo clone owner/repo komutuyla herkese açık olarak paylaşılmış herhangi bir depoyu bilgisayarınıza clone edebiliyorsunuz.
* gh issue status komutuyla açılmış tüm issue'leri ya da gh issue list --assignee [kullanıcı_adınız] komutuyla size atanmış tüm issue'leri listeleyebiliyorsunuz.
* gh pr create komutuyla Pull Request açabiliyorsunuz.
* gh pr checkout [PR_kodu] komutuyla reponuz için gönderilmiş bir pull requesti bilgisayarınıza checkout edebilir, sonrasında gh pr diff komutuyla değişiklikleri inceleyebilirsiniz ve son olarak da gh pr review --approve komutuyla checkout ettiğiniz Pull Request'in review aşamasından geçmesini onaylayabilirsiniz.
* Pull Request'i review ettikten sonra sonra gh pr checks komutuyla CI/CD süreçlerinde herhangi bir hata olup olmadığını kontrol edebilir sonrasında ise gh pr merge komutuyla Pull Request'in ilgili dal ile birleştirilmesini sağlayabilirsiniz.
* Son olarak da gh release create [etiket_ismi] komutuyla deponuza yeni bir sürüm çıkabilirsiniz.

Sadece bu komutlarla yetinmek zorunda değilsiniz elbette. GitHub aynı zamanda güzel bir iş yaparak tüm GitHub API'sini GitHub CLI üzerinden yapabilmenize olanak sağlayan alias özelliğini de aracına eklemiş. Dolayısıyla yapabildiğiniz şeylerin sayısı birden bire katlanıyor. Hemen her işini terminal ekranından yapmayı seven ben ve benim gibi #TerminalSevenlerDerneği üyelerini mutlu edecek güzel gelişmeler bunlar. İlerleyen sürümlerini de bekliyor olacağım 🙂

Duyuru yazısı: https://github.blog/2020-09-17-github-cli-1-0-is-now-available/
İndirme ve kurulum talimatları için: https://cli.github.com/

#GitHub #Programlama #YazılımGündemi #Terminal #KomutSatırı #API

BeğenFavori PaylaşYorum yap

OpenJDK projesinin Mercurial sürüm yönetim sisteminden Git'e ve barındırma için de GitHub'a taşınması işlemleri tamamlanmış. Proje artık GitHub üzerinde hayatına devam edecek.

Duyuru e-postası: http://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004694.html
OpenJDK'nın yeni evi: https://github.com/openjdk/jdk

#YazılımGündemi #Java #JDK #Git #GitHub

openjdk/jdk

JDK main-line development. Contribute to openjdk/jdk development by creating an account on GitHub.
BeğenFavori PaylaşYorum yap

TypeScript 4.0 sürümü duyuruldu.

Bu sürümle birlikte gelen özelliklerden biri de, yeni ECMAScript özelliğiyle birlikte eklenen, şu üç operatörün TypeScript'e de gelmesi oldu: &&= , ||= ve ??=.

Bu operatörlerle birlikte artık daha kısa kodlar yazabileceğiz. Örnek vermek gerekirse eskiden bu şekilde yazdığımız bir sorgu ifadesini:
if (!a) {
a = b;
}

Artık bu şekilde tek satıra indirebileceğiz: a ||= b

Ya da şu ifade yerine: (values ?? (values = [])).push("hello");
Bu ifadeyi kullanabileceğiz: (values ??= []).push("hello");

Yani artık daha anlaşılabilir/okunabilir ve kısa kodlar yazabileceğiz.

Bu sürümle birlikte gelen diğer özellik ve değişiklikler için bu blog yazısına bakabilirsiniz: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/

#Programlama #TypeScript #JavaScript #ECMAScript #YazılımGündemi #YazılımGeliştirme

BeğenFavori PaylaşYorum yap

Adobe, 2008 yılında duyurduğu web ve mobil için tek kod tabanından farklı cihazlarda çalışabilen uygulamalar çıkarmaya yarayan PhoneGap ve PhoneGap build araçlarını geliştirmeyi sonlandırıyor. PhoneGap Build hizmetinin 1 Ekim tarihinde kapatılacağını söyleyen Adobe aynı zamanda Apache Cordova açık kaynak projesi üzerindeki yatırımını da sonlandırıyormuş.

Haber kaynağı: https://blog.phonegap.com/update-for-customers-using-phonegap-and-phonegap-build-cc701c77502c

#HaftalıkGündemeMalzeme #Adobe #Mobil #Web #MobilUygulama #Programlama #YazılımGündemi

BeğenFavori PaylaşYorum yap

GitLab.com üzerinde GitLab Destek Ekibi çalışanları 15 Ağustos'tan itibaren ücretsiz hesapların iki-adımlı doğrulamasını kapatamayacak. Yani hesabınızın ve anahtarlarınızın güvenliğini sağlamak daha önemli olacak. GitLab şunları öneriyor:

* İki-adımlı doğrulama yedek kodlarınızı oluşturun ve güvenli bir şekilde saklayın,
* Donanımsal bir anahtar kullanın (YubiKey vb. gibi),
* Yedek kodlar oluşturabilmek için hesabınıza bir SSH anahtarı ekleyin.

Kısaca söylemek gerekirse GitLab artık "telefonunu/dizüstü bilgisayarını/tabletini ve yedek anahtarlarını kaybettiysen o hesabı unut" diyecek. İlkokuldayken okulda bir şeyimi unutunca annem "kendini de unutsaydın" derdi, bu da o hesap olmuş 😀

Bir anlamda güvenlik için iyi bir gelişme ama niye sadece ücretsiz hesaplar için geçerli bu anlamadım. Ücretli hesapların güvenliği daha önemli değil mi? Benim kaçırdığım bir detay mı var?

Kaynak: https://about.gitlab.com/blog/2020/08/04/gitlab-support-no-longer-processing-mfa-resets-for-free-users/

#HaftalıkGündemeMalzeme #GitLab #İkiAdımlıDoğrulama #SSH #2FA #YazılımGündemi

GitLab Support is no longer processing MFA resets for free users

From August 15th, GitLab Support will no longer be manually removing MFA from free accounts.
BeğenFavori PaylaşYorum yap

Git 2.28 sürümü yayınlanmış.

Bu sürümle birlikte artık git init komutuyla oluşturduğunuz yeni bir repository'nin varsayılan branch ismini değiştirebiliyoruz. Normalde bildiğimiz gibi git init çalıştırdığımızda varsayılan dal ismi olarak master kullanılıyor fakat artık bunu kullanmak istemeyenler için bir opsiyon var: init.defaultBranch. Bu opsiyonu gitconfig dosyanızı favori editörünüzle düzenleyerek ya da aşağıdaki gibi bir komut yardımıyla değiştirebilirsiniz:
git config --global init.defaultBranch anadal

Tabii ki bu değişikliğin sadece yeni oluşturacağınız repository'leri kapsayacağını belirtmek gerek. Bilgisayarınızda ya da uzak sunucudaki depolarınızın varsayılan dal ismini bu şekilde değiştiremezsiniz.

Diğer yenilik ve değişiklikler için GitHub Blog'da yayınlanmış şu blog yazısına bakabilirsiniz: https://github.blog/2020-07-27-highlights-from-git-2-28/

#Programlama #Git #YazılımGeliştirme #GitHub #Repository #YazılımGündemi

Highlights from Git 2.28 - The GitHub Blog

The open source Git project just released Git 2.28 with features and bug fixes from over 58 contributors, 13 of them new. We last caught up with you on the latest in Git back when
BeğenFavori PaylaşYorum yap

PHP 8'de isimli argümanlar (named arguments) özelliği geliyor. Yani artık aşağıdaki gibi bir kullanımı gerçekleştirebiliyor olacağız.
public function selamla(string isim, string soyisim = "", string email) {
//
}

selamla(isim: "Eren", email: "a@b.com");

Böylece fonksiyonu kullanırken varsayılan değeri olan argümanları atlayıp diğer argümanlara değer gönderebileceğiz.

Kaynak: https://stitcher.io/blog/php-8-named-arguments

#PHP #Programlama #YazılımGündemi #PHP8 #YazılımGeliştirme

BeğenFavori PaylaşYorum yap

Geçtiğimiz senenin kasım ayında yazılım gündemi yazısında haber verdiğim [1] GitHub'ın arşivleme projesinin Arctic World Archive kısmı tamamlanmış [2]. Toplamda 21TB boyutundaki veri filmlere yazılıp arşivlenmiş ve önümüzdeki 1000 yıl boyunca saklanmak üzere Svalbard'a gönderildi. Bu bağlamda arşive depoları eklenen kişilerin profillerine yeni bir rozet eklendi: Arctic Code Vault Contributor. Bana da eklenmiş. Aktif olarak GitHub kullanan çoğu kişinin profiline eklenmiştir kontrol edebilirsiniz.

[1]: https://teknoseyir.com/blog/yazilim-gundemi-18-11-17-kasim-2019
[2]: https://github.blog/2020-07-16-github-archive-program-the-journey-of-the-worlds-open-source-code-to-the-arctic/

#GitHub #Programlama #Arşiv #Vault #YazılımGündemi

BeğenFavori PaylaşYorum yap

Microsoft, Windows için PHP resmî desteğini sonlandırıyor.

• PHP 7.2 versiyonunun desteği Kasım ayında bitiyor.
• PHP 7.3 versiyonu Kasım ayından sonra sadece güvenlik güncelleştirmeleri alacak.
• PHP 7.4 versiyonu bir yıl hata giderme (bug fix) ve bir yıl da güvenlik güncelleştirmeleri olmak üzere önümüzdeki 2 yıl boyunca desteklenecek.
• PHP 8.0 ve sonraki sürümler Microsoft tarafından resmî olarak desteklenmeyecek.

Bunlar tabii ki de “Windows’da artık PHP çalışmayacak” anlamına gelmiyor. Sadece Microsoft’un sunduğu resmî sürümler ve destek artık olmayacak. Onun yerine PHP kendi içerisinde bir yapılanmaya gider ya da topluluk tarafından desteklenmeye devam eder. Microsoft artık katkı yapmayacak. Geliştiriciler için bir şey değişeceğini sanmıyorum.

Haber Kaynağı: https://laravel-news.com/microsoft-dropping-php-support
Microsoft yetkilisinin PHP mail grubuna gönderdiği duyuru: https://news-web.php.net/php.internals/110907

#Programlama #YazılımGündemi #Microsoft #Windows #PHP

Microsoft Announces that it will drop official support of PHP on Windows

Dale Hirt, the project manager for PHP inside Microsoft, announced this week on the PHP mailing list that Microsoft is no longer going to offer official support of PHP on Windows starting at v8
BeğenFavori PaylaşYorum yap
  • Synth @synth

    Windows'un neden ve nasıl PHP desteği varmış, anlamadım

    • Robin @robin

      @merphous Php candır neden ölsün ki ?

    • Mert @merphous

      @erenhatirnaz @robin Rezalet bir dil olduğu için? Gerçi javascriptin de ondan kalır yanı yok ama.

    • Eren Hatırnaz @erenhatirnaz

      @merphous Neye göre rezalet bi' dil mesela? Örnek verebilir misin? Ayrıca bu kadar "rezalet" bir dilse niye web'in büyük bir çoğunluğu PHP kullanıyor? Programlama dillerini birer araç olarak görüp, işinize yarayan projelerde kullanmak varken neden bir programlama dilinden nefret ediyorsunuz?

    • Mert @merphous

      @erenhatirnaz Dilden nefret etmiyorum. Ancak dili savunmanızdan, sizin bahsettiğiniz şekilde davranmadığınız anlaşılıyor. Çokça kullanılması, bir dili iyi yapmıyor. PHP ve Javascriptte syntax ve dilin yapısı type safety açısından olsun, hatalara geçit verme konusundan olsun, kodun bug yuvası olmasına müsade ediyor. Bundan dolayı ki, 2020 yılı olmasına rağmen web sayfaları saçma sapan hatalar veriyor, yavaş yükleniyor, düşük fps'te çalışıyor vs. Dilin ölmesini isteme nedenim, ortaya çıkardığı sorunlardan kaynaklı. Yoksa dil fanatikliği gibi bir eblehlikten değil.

    • Robin @robin

      @merphous Type safety olup olmaması bir zorunluluk değil ki type safety olmayınca dil kötü mü oluyor ? Ruby ve php geliştirici odaklı dil olduğu için her türlü kodu mümkün olduğunca çalıştırmaya çalışacak şekilde tasarlanıyor ona göre syntax ları var. Java ve .net de her şey katı kuralı var type check efsane çalışıyor diyip php yi kötülemeniz çok manidar. Acaba php dışında hangi dillerde ne kadar kod yazdınız da php nin bu kadar kötü olduğuna kanaat getirdiniz ?

    • Eren Hatırnaz @erenhatirnaz

      @merphous Daha hiçbir savunma yapmadım bile. Sadece hiçbir argüman belirtmeden "ölsün artık", "rezalet bir dil ondan" gibi söylemlerinizin arkasındaki nedeni sorguladım o kadar. Sanırım PHP 5'den eski sürümlerde kaldınız siz. PHP 5 ve özellikle PHP 7'den sonraki gelişmelere bakmanızı tavsiye ederim. Ek olarak kötü yazılmış her kod dil fark etmeksizin kötü çalışır. Type Safe olayında Robin'in söylediklerine katılıyorum. Her dil Type Safe olmak zorunda değil; bu bir dil tasarımı kararıdır. Kaldi ki son sürümlerde Type Safe desteği de giderek artıyor.
      Ben de herhangi bir programlama dilinin fanatiği değilim. Projeye uygun dil hangisiyse onu kullanırım. Hiçbir programlama dili için "ölsün artık" demiyorum.

    • Mert @merphous

      @robin @erenhatirnaz her türlü kodu mümkün olduğunca çalıştırmaya çalışması iyi bir şey değil. bundan dolayı yarım yamalak çalışan, kötü kullanıcı tecrübesi sunan, yıllarca bug fixlenmesi gereken ürünler ortaya çıkıyor. Bu nedenle projeye uygun dil diye bir şey olmadığı gibi bir iddiam olmamasıyla beraber, php ve javascript dillerinin bu tarz rezillikler nedeniyle buglara gebe olmasına serzenişte bulunuyorum.

    • Robin @robin

      @merphous O zaman php kötü olmasına rağmen neden bunca firma ve geliştirici hala bu dili tercih edip onunla büyük projeler yapıyor ? Dil buna izin veriyor diye yazılan tüm projeler çöp olacak diye bir şey yok. Eğer dil belirli kalıplara sokuyorsa geliştiriciyi kötü kod yazmama konusunda kısıtlama ve bazı şeylerin tek çözümü olduğundan kaynaklanıyor. Ama eğer bir dilde kötü kod yazılabiliyorsa o da geliştiriciyi özgür bırakmasından ve geliştiricinin yeterince programlama temeli olmamasından kaynaklanıyor. Yani php ile yapılmış bu kadar kötü projenin olmasının sebebi dil değil yeterli bilgisi olmayan geliştiricilerdir

    • Mert @merphous

      @robin Aynı şeyi yüz elli kez yazmam mı lazım? Dilin çokça kullanılması dili iyi yapmıyor diyorum. Sorun geliştiricilerde demek sadece dilin pejmürdeliğini kapının altına süpürmektir. Nitekim, iyi bir dil zaten bu tarz buglara mümkün olduğunca el vermeyecek şekilde tasarlanan dil oluyor. Bu dillerin ölmesi ve yerine düzgün dillerin almasını umut ediyorum gelecekte.

    • Ufkabakan @ufkabakan

      @merphous Sen istiyor type safe, strong, bug free code, sen kullanacak ADA

  • Ufkabakan @ufkabakan

    ISS üzerinde PHP site çalıştıranları üzerler sadece. Gerçi onlarda kendileri derleyip çalıştırırlar olmadı. Zaten profesyonel şekil de PHP site host edip, Linux makine kullanmamakta ne bileyim, ilginç olur.

Daha önce yazılım gündemi yazısında da haber verdiğim [1] gibi Python 2.x sürümleri aramızdan ayrıldı. Bundan sonra Python dili tek sürüm üzerinden devam edecek. Python 2 ile yazılmış aktif projelerinizi Python 3'e geçirmeniz tavsiye edilir. Nasıl bilirdiniz rahmetliyi?

https://pythonclock.org/
https://www.python.org/doc/sunset-python-2/

[1]: Yazılım Gündemi - 9: https://teknoseyir.com/blog/yazilim-gundemi-9-9-15-eylul-2019

#Python #Programlama #YazılımGündemi

BeğenFavori PaylaşYorum yap