it-swarm-tr.com

Her programcı hangi sysadmin şeylerini bilmeli?

Bir programcı olarak sistem yöneticilerini kabul etme eğilimindeyiz. İyi bir sysadmin olmadan birkaç kez gerçekten bana ne yaptığını takdir etti. Sisadminsiz bir ortama girerken, bize hangi bilgelik sözlerini sunabilirsiniz?

96
Nathan DeWitt

Şununla başlıyorum:

  1. Her zaman bir tür yedekleme sistemi vardır. Bir geçmişi varsa daha da iyi.
  2. Tek hata noktalarını ve başarısız olmaları durumunda onlarla nasıl başa çıkılacağını düşünün.
  3. İlgili bilgisayarların miktarına bağlı olarak, bilgisayarlar arasında standart bir görüntü oluşturmanın ve oluşturmanın bir yolunu aramak herkesin hayatını kolaylaştıracaktır - hayır "benimki üzerinde çalışıyor" çünkü böyle bir program ve normalde yüklü olmayan bir program var.
  4. Her şeyi belgeleyin, eğer sadece bir şeyi nasıl ayarladığınızı unutacaksa .
  5. Güvenlik güncellemelerini takip edin.
70
Chealion

<buraya büyük yazı feragatnamesi ekleyin>

Bunlardan bazıları daha önce söylendi, ancak tekrar etmeye değer.

Belgeler:

  • Her şeyi belgeleyin. Eğer bir hesabınız yoksa, radar altı bir wiki yükleyin, ancak yedeklediğinizden emin olun. Gerçekleri toplamaya başlayın ve bir gün büyük bir resim oluşacaktır.

  • Her mantıksal yığın için diyagramlar oluşturun ve bunları güncel tutun. Doğru bir ağ haritası veya küme diyagramının beni kaç kez kurtardığını sayamadım.

  • Her bir sistem için derleme günlüklerini tutun, sadece nasıl oluşturulacağına ilişkin komutları kopyalayıp yapıştırsanız bile.

  • Sisteminizi oluştururken uygulamalarınızı yükleyin ve yapılandırın, çalıştığını test edin ve kıyaslama yapın. Şimdi diskleri silin. Ciddi anlamda. disklerin önündeki ilk megabaytı 'dd' veya kutuyu önyüklenemez hale getirir. Saat işliyor: belgelerinizin sıfırdan yeniden oluşturabileceğini kanıtlayın (veya daha da iyisi, meslektaşınızın belgelerinizden başka bir şey olmadığını kanıtlayın). Bu, Olağanüstü Durum Kurtarma planınızın yarısını oluşturacaktır.

  • Artık Olağanüstü Durum Kurtarma planınızın ilk yarısına sahipsiniz, gerisini belgeleyin; uygulamanızın durumunu nasıl geri alabilirsiniz (dosyaları banttan geri yükleyin, veritabanlarını dökümlerden yeniden yükleyin), satıcı/destek ayrıntıları, ağ gereksinimleri, yedek donanımı nasıl ve nereden alacağınız - aklınıza gelebilecek her şey sisteminizin yedeklenmesine yardımcı olacaktır.

Otomasyon:

  • Olabildiğince otomatikleştirin. Üç kez bir şey yapmanız gerekiyorsa, ikincisinin otomasyonunuzu geliştirmek için harcandığından emin olun, böylece üçüncüsü tamamen otomatik olur. Otomatikleştiremiyorsanız, belgeleyin. Orada otomasyon paketleri var - onları sizin için çalıştırabilir bakın.

İzleme:

  • Uygulama aletleri saf altındır. Sistemden geçen işlemleri izleyebilmek hata ayıklamayı ve sorun gidermeyi çok daha kolay hale getirir.

  • Yalnızca uygulamanın canlı olduğunu kanıtlamakla kalmayıp aynı zamanda olması gerekeni gerçekten de kanıtlayan uçtan uca testler oluşturun. Uyarı amacıyla izleme sistemine girilebiliyorsa puanlar sizindir. Bu çifte görev yapar; uygulama çalışmalarını kanıtlamanın yanı sıra, sistem güncellemelerini önemli ölçüde kolaylaştırır (sistem raporlarını izleme yeşil, yükseltme çalıştı, eve gitme zamanı).

  • Bunu yapmak için her şeyin ölçütünü, izlemesini ve metriklerini toplayın. Testler, bir şeyin sihirli dumanı bırakmasını ne zaman bekleyeceğinizi söyler. İzleme size ne zaman olduğunu söyler. Metrikler ve istatistikler, yönetim yoluyla yeni kit (taze sihirli dumanla) almayı kolaylaştırır.

  • Bir izleme sisteminiz yoksa bir tane uygulayın. Yukarıdaki uçtan uca testleri gerçekten yaparsanız bonus puanlar.

Güvenlik:

  • "chmod 777" (diğer adıyla tüm erişim/ayrıcalıkları verme) hiçbir zaman çözüm değildir.

  • 'En az bit' prensibine abone olun; yüklü değilse, kopyalanmamışsa veya başka bir şekilde disk üzerinde yaşamıyorsa, ödün verilemez. "Mutfak lavabosu" işletim sistemi ve yazılım yüklemeleri, oluşturma aşamasında hayatı kolaylaştırabilir, ancak bunun için pistte ödeme yaparsınız.

  • Bir sunucudaki her açık bağlantı noktasının ne için olduğunu bilin. Yenilerinin görünmemesini sağlamak için sık sık denetleyin.

  • Güvenliği ihlal edilmiş bir sunucuyu temizlemeyi denemeyin; sıfırdan yeniden inşa edilmesi gerekiyor. Yeni indirilen medyaya sahip yedek bir sunucuya yeniden yükleyin, yalnızca yedeklemelerdeki verileri (ikili dosyalar tehlikeye girebileceğinden) geri yükler veya aynı kitle yeniden oluşturabilmeniz için güvenliği ihlal edilmiş Ana Bilgisayarı analiz için izole bir yere kopyalayın. Bunun etrafında tam bir yasal kabus var, bu yüzden yasal yollara gitmeniz gerektiğinde koruma tarafında hata var. (Not: IANAL).

Donanım:

  • Asla kutuda söylediklerini yapacak bir şey olduğunu varsaymayın. İhtiyacınız olan şeyi yaptığını kanıtlayın, eğer olmazsa. Kendinizi beklediğinizden daha sık "neredeyse işe yarıyor" diyerek bulacaksınız.

  • Uzaktan donanım yönetimini gözden kaçırmayın. Seri konsollar ve aydınlatma yönetimi zorunlu tutulmalıdır. Seçeneklerinizin olmadığı zamanlarda uzaktan kontrol edilen anahtarlı uzatma kabloları için bonus puan.

(Bir yana: Bir sorunu sabah 3'te düzeltmenin iki yolu var, biri sıcak olmayı, pijamalarınızdaki bir VPN üzerinde bir dizüstü bilgisayarda çalışmayı, diğeri kalın bir ceket ve veri merkezine/ofise götürmeyi içeriyor. tercih etmek.)

Proje Yönetimi:

  • Proje yaşam döngüsünün ilk gününden itibaren sistemi koruyacak insanları dahil edin. Kit ve beyin zamanındaki teslim süreleri sürpriz olabilir ve olacak ve proje bağımlılıkları haline gelecek standartlara veya gereksinimlere sahip olacaklarından hiç şüphesiz.

  • Dokümantasyon projenin bir parçasıdır. Proje kapatıldıktan ve sistem bakıma alındıktan sonra her şeyi yazmak için asla zaman bulamazsınız, bu yüzden başlangıçta programa çaba olarak dahil edildiğinden emin olun.

  • Planlanan eskimeyi ilk günden itibaren projeye uygulayın ve proje belgelerinde belirttiğiniz kapanma gününden altı ay önce yenileme döngüsüne başlayın.

Sunucular, üretimde kullanım için uygun olduklarında tanımlanmış bir ömre sahiptir. Bu kullanım ömrünün sonu genellikle, satıcının yıllık bakımda kiti yenilemeye göre daha fazla şarj etmeye başladığında veya hangisi daha kısasa üç yıl olarak tanımlanır. Bu süreden sonra, geliştirme/test ortamları için mükemmeldirler, ancak işi yürütmek için onlara güvenmemelisiniz. Ortamı 2 1/2 yılda yeniden ziyaret etmek, yeni kitin sipariş edilmesi için gerekli yönetim ve finans çemberlerine atlamak ve eski kiti gökyüzündeki büyük satıcıya göndermeden önce düzgün bir geçiş yapmak için bolca zaman verir.

Geliştirme:

  • Geliştirme ve evreleme sistemlerinizin üretime benzediğinden emin olun. VM'ler veya diğer sanallaştırma teknikleri (bölgeler, LDOM'lar, vservers) her anlamda gerçek dünyada performans klonlarını kolaylaştırır.

Yedekler

  • Yedeklemediğiniz veriler istemediğiniz verilerdir. Bu değişmez bir yasadır. Gerçekliğinizin buna uygun olduğundan emin olun.

  • Yedekler göründüğünden daha zordur; bazı dosyalar açık veya kilitli olurken, diğerlerinin kurtarma umuduna sahip olması için sessiz olması gerekir ve tüm bu sorunların çözülmesi gerekir. Bazı yedekleme paketleri açık/kilitli dosyalarla ilgilenmek için aracılara veya başka yöntemlere sahiptir, diğer paketlerde yoktur. Veritabanlarının diske dökülmesi ve yedeklenmesi, bir "sessizleştirme" biçimi olarak sayılır, ancak tek yöntem bu değildir.

  • Test edilmedikçe yedeklemeler değersizdir. Birkaç ayda bir rastgele bir bandı arşivlerden çıkarın, üzerinde gerçekten veri bulunduğundan ve verilerin tutarlı olduğundan emin olun.

Ve en önemlisi...

Başarısızlık modlarını seç, yoksa Murphy ... ve Murphy programında çalışmıyor.

Başarısızlık için tasarım yapın, her sistemin tasarlanmış zayıf noktalarını, onları neyin tetiklediğini ve nasıl kurtarılacağını belgeleyin. Bir şeyler ters gittiğinde fark yaratacak.

44
Greg Work

Kolay olduğunu varsaymayın. Ben sadece bir web çiftliği çalıştırabilirsiniz IIS veya Apache dev kutusu kurabilirsiniz çünkü düşünen birçok programcılar biliyorum.İşin ne içerdiğini anlamak ve araştırma ve planlama yapmak, yapma t Sadece sysadmin çalışmasının uygulamanızı dağıtmak için 10 dakika içinde yapabileceğiniz kolay bir şey olduğunu düşünün.

43
Sam Cogan
  • İyi ya da kötü, sunucuların ve/veya ağ donanımlarının çoğunun ikinci bir aileden gelen çocuklara çok benzediğini fark edin. Bunlar onların bebekleridir. Onlara eğilim gösterirler, hasta olduklarında yardımcı olurlar ve sorun için onları dikkatle izlerler. Bu bu şekilde olmamalı , ancak yıllar sonra sık sık . Onlara, ekipmanların düzgün çalışmadığı veya beklenti ile ilgili endişelerinizi ilettiğiniz için aklınızda bulundurun. Ve anlamadığınız bir yanıt alırsanız, bu dünya görünümü üzerinden filtrelemeyi deneyin.
  • İyi çalışma koşullarında olun. Kulağa hoş geliyor, ama ağırlığı altın değerinde. Bir gün, özel bir iyiliğe ihtiyacınız olacak. Ve bir gün, bu sysadmin hayatı sizin için biraz daha kolay hale getirmek için kendi yolundan çıkmaktan mutluluk duyacaktır, sadece bir kez.
  • Bu çalışma ilişkisi her iki yöne de gider. Sysadmin çok meşgulse ve küçük bir komut dosyası veya program yazarak hayatı biraz daha kolaylaştırabilirseniz, yapın! Bildiğinizden daha çok takdir edecekler.
  • Çok açık olun. "Bu berbat" kadar net değil "aralıklı bir ağ bağlantısı olması biraz can sıkıcı, bakmak için herhangi bir şans?"
  • Uygulamanızın ölçeklendirileceğini düşünüyorsanız, önce varsayarak yöneticinize sorun. Görmediğiniz bir şeyi "görebilir" veya dağıtacağınız ekipmanın performans sınırları hakkında bir şeyler biliyor olabilirler.
  • Uygulamanızın ayarlanması gerekiyor, ancak bir kod sorunu gibi görünmüyorsa, sunucuların nasıl performans gösterdiğini sorun. Sistem yöneticileri, makinelerini sevgi dolu bir bakım ile eğilimlidir ve "hasta" veya "kötü davranış" olduklarında memnun olmazlar. Güzel bir şekilde sormak bir hasta makinesini ters çevirir (veya tamir edilmesini/değiştirilmesini sağlar).
  • (başka bir yerde belirtildiği gibi) kullandığınız ayarları ve neden kullandığınızı belgeler. Sadece "set checkbox X" veya "uncomment config file line Y" yardımcı olmaz. Bildiğiniz herkes için bir sonraki önyüklemedeki tüm verilerinizi silen seçeneği ayarlıyor olabilirsiniz.
  • Ayarı kağıda dokümante etmek için zamanınız yoksa, mümkünse sistemde dokümante etmeye çalışın. Yapılandırma dosyalarında bu neredeyse standart bir uygulama olmalıdır - her ayar değişikliğinin tarih damgası, baş harfleri, o ayarın beklenen etkisi ve nedeni neden olmalıdır değiştirildi (önceki madde işaretine bakın). Bu küçük alışkanlık, krizi sırasında pastırmamı bir kereden fazla kurtardı. "Bunu neden yaptık?" "Çünkü X politikasını zorunlu kıldık ve Y ayarı bize X politikası için ihtiyacımız olan davranışı veriyor".
  • Bira. Veya Cola. Hatta su. İçecekler her zaman memnuniyetle karşılanmaktadır. Sisadmin olmak susuz bir iştir.
27
Avery Payne

Güvenlik sonradan düşünülmez. Saldırıya uğramış bir uygulama programcının yetersiz görünmesine rağmen, (en azından) bir sistem yöneticisi için yedeklemeleri doğrulamak, temizlemek ve/veya geri yüklemek için harcanan kayıp bir hafta sonu.

Bu nedenle, yedekleri sürüm kontrolü olarak ele almayın. Felaket kurtarma amaçlıdır ve kodunuzu geri yüklemek için gerçekten tasarlanmamıştır, çünkü ne değiştirdiğinizi unuttunuz.

Kodunuzun kırılması için Windows Update'i körü körüne suçlamayı bırakın. Beforte işe yaradığı umrumda değil, neden şimdi işe yaramadığını söyle - o zaman kimin hatası olduğunu görebiliriz.

23
Mark Brackett

Ağ sorunlarını ayıklama ve programınızın sysadmin araçlarıyla çalışmasını izleme. Sistem yönetimine başlayan bir programcı olarak, ağ oluşturduktan sonra pek çok programcının ne kadar güçsüz hale geldiğine şaşıyorum.

  • Wireshark, kodunuzun kara kutu şeklinde çalışmasını izlemek için, paket paket
  • Doğrudan ağ hizmetlerine bağlanmak için araçlar:
    • Telnet, netcat veya socat TCP veya UDP) üzerinden düz bağlantılar için
    • OpenSSL şifreleme ile aynı şey için (ipucu: try openssl s_client -connect target-Host:port bazen), ağ hizmetlerine manuel olarak bağlanmak için
  • Dig (BIND 9 paketinde) ad çözümlemesinde hata ayıklama için
  • Başarısız bir bağlantının zamanlamasına ve diğer özelliklerine bağlı olarak ağ yığınının hangi bölümünün başarısız olduğunu söyleyebilme
  • Muhtemelen HTTPFox ve/veya Firebug
17
jhs

Sorunların nasıl giderileceğini öğrenin.

Buck'i geçmek çok kolay (örneğin, ağınız veritabanı ile iletişimimi sürdürüyor). Ağın hatası olabilir, ancak Google veya SO kullanarak bir uygulamanın yapılandırmasında bir sorun ortaya çıkarabilecek hatalara sahip uygulama günlüklerine sahip olmalısınız.

Herkes donanımı, işletim sistemini veya ağı suçlamayı sever, bu yüzden biraz daha özenli davranırsanız, sistemadını mutlu bir insan yaparsınız. Çünkü, başka bir şey yoksa, bunları neyin yanlış olabileceğine ("ağınız berbat" veya eşit derecede yararlı bir şey söylemenin aksine) belirli bir yöne yönlendirebilirsiniz.

14
Milner

Yapabileceğiniz her şeyi belgeleyin. Son sysadmin kaç kez 'iş güvenliği' için bir şey belgelemenin sevimli olacağını düşündü ya da sadece içeri girmek ve çıkmak istedim. Tıpkı bir programcının iyi yorumlar bırakması gibi, sistem yöneticileri de belgelemelidir. Topolojinin bir diyagramı da güzel olurdu.

8
Terry

B planı.

Bir çözüm tasarlarken ve geliştirirken her zaman bir felaket kurtarma planını göz önünde bulundurun. Bir kesintiye yol açabilecek tek hata noktalarını tanımak.

7
spoulson

Dokümantasyon: deliğe gitmeye gerek yok, ancak uygulamanın nasıl çalıştığını, bitlerin nasıl oturduğunu ve her bir bileşen yanlış gittiğinde test etmenin yollarını gösteren bir diyagram. Örnek veri ve çıktı güzel.

Gereksinimler: hangi modüllere güveniyor? Sürümleri? İŞLETİM SİSTEMİ?

İzleme: ideal olarak geliştiriciler uygulama ile izleme ve bilgi izleme içerir.

Ambalajdan bahsetmişken, AMBALAJ! "Dağıtım" dan daha kötü bir şey değildir, bu da VCS'den bir dosyanın yeni bir revizyonunu kontrol etmek ve bir grup sunucuya kopyalamak anlamına gelir. Çoğu zaman programcılar yazılım dağıtımının karmaşıklığını takdir etmezler: sürümlendirilmiş, paketlenmiş yazılımların çoğu işletim sisteminin bel kemiğini oluşturmasının nedenleri vardır.

Bir geliştirici bana ilk, kısa, kapsamlı belgeler ve bazı Nagios testleri ile kurulan bir RPM ile geldiyse, yeni en iyi arkadaşım olurdu.

6
markdrayton

Şimdiye kadar verilen 17 cevaptan hiçbirinin, uygulamanızın standart kullanıcı olarak oturum açtığında çalışmasını sağlama hakkında bir şey içermesine şaşırdım.

Yükleme işlemi dışında, standart bir kullanıcı hesabıyla oturum açıldığında uygulama düzgün çalışmalıdır.

6
Bryan
  • ne yaptığınız hakkında resmi ve gayri resmi olarak yöneticinizle konuşun. Genellikle ilgilenirler ve erken üretim üzerindeki olası etkileri ifade edebilirler. Kabul etmek zorunda değilsiniz, ancak sorunlu noktaların belirlenmesine yardımcı olur.
  • Hayır, sunucunun tamamı kendinize sahip olamaz ... Gerekirse, teknik olarak ne kadar sağlam olduğuna bakılmaksızın politik bir karardır. Politikayı çalışmak istiyorsanız, hemen devam edin.
  • Üretim donanımı genellikle geliştirme sunucunuzdan ve çiftliklerde bile makinelerdeki özelliklerin farklı olduğundan farklı görünür.
  • Üretimin nasıl kurulduğunu öğrenin, çünkü muhtemelen masaüstünüzde çoğaltamazsınız, bunu yapmak kötü varsayımlar yapmanıza engel olur.
  • Bellekte bir şeyler önbellekleyebilmeniz gerektiği anlamına gelmez, önce darboğazı bekleyin (birim testinde veya üretim öncesi performans testinde)
  • bir veritabanına veri yapıştırıyorsanız, verileri nasıl salt okunur verilere (yatay olarak ölçeklendirilebilir) ve okuma-yazma verilerine (genellikle yalnızca dikey olarak ölçeklenir) nasıl ayırabileceğinizi düşünün.
  • bir veritabanına veri yapıştırma, gerçekten bir RDBMS olmalı? daha iyi ölçeklenen (netcache) başka anahtar/değer çifti sistemleri de vardır.
  • düşünme AJAX sonuçta çözüm, havalı görünüyor, ancak izleme ve otomasyon olanaklarını sınırlıyor. Bunu kullanma demiyorum, sadece iki kez düşünün.
4
ericslaw

Tamam bu biraz ranting ama:

a) Kodlama yaparken, altta yatan altyapının başarısız olabileceğini ve her zaman mutlu-mutlu topraklardan gelmediğini varsayın. Veya Google.

b) Muhtemelen okuduğunuz altyapı gibi bir şeyi uygulayacak kaynaklara sahip değiliz. Muhtemelen ne yapılması gerektiğini biliyoruz, ancak herhangi bir nedenle henüz gerçekleşmedi. Biz ortaklarınızız!

c) Yukarıda bahsedilen jh'ler gibi, ping, traceroute (veya her ikisini - mtr birleştirmek), Dig, vb. gibi altyapı sorunlarını gidermek için araçlara aşina olmanız gerçekten yararlı olacaktır.

d) Bir bilgisayarı programlıyorsanız, ağa nasıl bağlandığını ve ipconfig/all veya ifconfig çıktısını ayrıştırma gibi temel bilgileri bilmelisiniz. En az yardımla internet bağlantınızı kurup çalıştırabilmelisiniz.

Aksi takdirde Avery'nin hemen hemen çivilenmiş olduğunu düşünüyorum. Biraz sysadmin yapan geliştiriciler ağırlıklarının altın değerinde! Ancak aynı şekilde, geliştiricilerin bir şeylerle (sürüm oluşturma dahil) nasıl gittiğini anlayan sistem yöneticileri bu gün ve yaşta oldukça önemlidir.

Bu şu anda havada gibi görünüyor, bloglardaki dev/ops ilişkisi hakkında daha fazla tartışma fark ettim.

Twitter'ı Twitter'da Tutmak

Bölmeler ve Savaş

İşlemlerde İlk Test

4
Cawflands

Yedekleme Yedekleme Yedekleme .... Yedeklemeyi test edin .... Her zaman geri dönmeye hazır olun

4
trent

Bu sadece yeni başlayan programcılar için geçerli olabilir, ancak bazı programcılar ile her projede birkaç şeyle ilgileniyorum.

  1. "Bu benim makinemde çalışır" geçerli bir ifade değildir. Sunucuda kullanılmak üzere bir yükleme programı oluşturmak veya en azından sunucuda gerekli olacak her bağlantı, dll ve eklentiyi belgelemek programcının sorumluluğundadır.

  2. (Bunu birçok kez duydum, bu yüzden lütfen gülmeyin) Exe'yi makinemden sunucuda çalıştırıyorum ve çalışıyor. Ancak, sunucuda (Citrix, Terminal Server, vb.) Çalıştırdığımda çalışmıyor. Lütfen dll ve ocx'leri ve programınızın gerektirdiği her şeyi ve bunların nerede ve nasıl kaydedildiğini ve programınızın bunları nasıl kullandığını anlayın.

Bunlar basit görünebilir, ancak bununla sürekli ilgileniyorum.

Brian

4
Brian

Hiçbir grup veya işlevin diğerinden 'daha iyi' olmadığı ve hiçbirinin de birbirinden 'daha büyük beyin' gerektirmediği. Her iki tarafın da diğer şirketin tüm prima-dona'ish'lerini aldığını gördüm - hepiniz aynı hedeflere ulaşmaya çalışıyorsunuz - farklı araç kullandığınız gerçeğine değil, bu benzerliklere odaklanın.

3
Chopper3

Altyapı mimarı programcıya döndü, gelecekte bu işlemi geri almak isteyebilir :)

  1. Birbirinizle erken ve sık sık konuşun. Tasarımları, uygulamanızın dağıtılacağı altyapıyı yönetecek olanlarla (bunun kim olacağını biliyorsanız) inceleyin.
  2. Sıfır veri kaybı mümkündür, ancak geliştiriciler ve sistem yöneticileri tarafından paylaşılan bir sorumluluktur. Yine, birbirinizle konuşmak burada yardımcı olabilir.
  3. Altyapı personelinizin işlevsel olmayan gereksinimleri belirlemede yer almış olması gerekir.
  4. Bira (iş bittiğinde) ve pizza (çalışırken) düzenleyin. Her nasılsa, bu tür yiyeceklerin varlığı, Nice küçük 32 cpu kutularımızı yapmalarını istediğiniz her şeyi yapma yeteneğimizi etkiler :)
2

Geliştiriciler için bir sys yöneticisi ve kendim bir geliştirici olarak, burada verilen tavsiye sadece altın değil, aynı zamanda tüm şirketler için yeni geliştiriciler için işe alma belgelerinin bir parçası olmalıdır.

Görmediğim (henüz) bir şey, geliştiricilerin, kendilerine ödenen programları oluşturmak için kullanacakları ürünleri gerçekten bilmeleri gerektiğidir. Geliştirici makinelerde Apache sunucularını, Eclipse ve Visual Studio yüklemelerini ve veritabanını açıklamak ve yapılandırmak zorunda kaldığım miktar biraz endişe vericidir.

2
canadiancreed