Organize Usings

[Oğuzhan YILMAZ]

Hani vs.net kod ekranında sağ tıklarsın, açılan menüden "Organize Usings", sonra Remove and Sort dersin ya. Elin mouse'a gidinceye kadar 0.5sn geçer, sağ tıkla + menüye gir 1,5 sn. mouse'a bas 0,2 sn. 

Bunun bir kısa yolu yok mu? illene böyle takla mı atmak lazım bir tuşa atamak için, macrolarla yapılıyor ama bazen çalışıyor, bazen çalışmıyor. Varmı başka kullanılmayan snamespace'lere takıntılı olan? :)

--
Oğuzhan

[ersin caliskan]

Resharper Alt+Enter+Enter :)  Dediğin şekilde remove etmek cok zor.

--
You received this message because you are subscribed to the Google Groups "altdotnetturkiye" group.
To post to this group, send email to altdotne...@googlegroups.com.
To unsubscribe from this group, send email to altdotnetturki...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altdotnetturkiye?hl=en.

--
Ersin Çalışkan

[Mehmet Zahir SOLAK]

Merhaba,

Tools > Options penceresinden Keyboard 'u seçin. Komutlardan Edit.RemoveAndSort 'u seçin. Press shortcut keys'e dilediğiniz kısayolu girip Assign'a tıklayın. Hepsi bu kadar :)

2012/4/3 Oğuzhan YILMAZ <asp...@gmail.com>

--
Oğuzhan

[Berat Bilgin]

Birde şurası var.

3 Nisan 2012 13:43 tarihinde Mehmet Zahir SOLAK <zahir...@gmail.com> yazdı:

--
Berat Bilgin

[Oğuzhan YILMAZ]

Tamam o tanımlı da ama düzgün çalışmıyor. Yani bir çalışıyor, ikinci çalışmıyor. Kafasına göre. ?

3 Nisan 2012 14:43 tarihinde Mehmet Zahir SOLAK <zahir...@gmail.com> yazdı:

--
Oğuzhan

[Sidar Ok]

Abi resharper iyi ho$ da kullanmak icin jedi olmak lazim resmen, kisayollarin varliklarini hatirlamak , mesele

2012/4/3 Oğuzhan YILMAZ <asp...@gmail.com>

--
Sidar Ok

http://www.sidarok.com
http://www.twitter.com/sidarok

[Emre Mert Asyalıoğlu]

Ben bunu yapıştırdım monitor uzerine bi süre sonra bakmıyosun bile :)

http://www.jetbrains.com/resharper/docs/ReSharper60DefaultKeymap_VS_scheme.pdf 

3 Nisan 2012 15:20 tarihinde Sidar Ok <sid...@gmail.com> yazdı:

--
Emre Mert Asyalıoğlu

[Sidar Ok]

I$kence yaw dil ogrenir gibi :) Artik ortamlarda resharper ca konU$uruz

2012/4/3 Emre Mert Asyalıoğlu <easya...@gmail.com>

[Mehmet Zahir SOLAK]

ReSharper'ı iyi güzel, seviyoruz da. Ancak vs'in performasını iyice düşürüyor. Özellikle bol projeli solutionlarda..

2012/4/3 Sidar Ok <sid...@gmail.com>

[Eralp Erat]

malesef.SSD Disk+yüksek performans makine..anca..

2012/4/3 Mehmet Zahir SOLAK <zahir...@gmail.com>

[Cengiz Han]

Resharper olmadan buyuk bir projede bir dosya acmak/bulmak bile dert. Kisayollar ogrenmesi zor gelsede 1 ay falan kullaninca yerlesmeye basliyor.

Bence kesinlikle olmazsa olmaz bir tool .net developerlari icin.

Sent from my iPhone

[Doga Oztuzun]

Resharper olmayan VS'de kod yazamaz olduk.

2012/4/4 Cengiz Han <cen...@cengizhan.com>

--
http://www.DogaOztuzun.com/

[Mehmet Zahir SOLAK]

CodeRush deneyen oldu mu? Ben pek kullanamadım :)

2012/4/4 Doga Oztuzun <unq...@gmail.com>

[Halil Bozdogan]

CodeRush Express kullanıyorum, Free olarak verildiği için lisans kaygım da yok.

Açıkçası 300 küsürlük projede VS'e bir etkisi olmuyor,

Güzel özellikleri var, çizgisi ettisi felan iyi. Belki code analysis yapmıyor ama zaten işin kastığı kısım da orası, onun dışında güzel kısa yollar getiriyor ve sizi zorlamıyor. kısa yolları da eğer VS ile çakışırsa, söylüyor, hangisini istiyorsun diye.

Denemenizi öneririm.

2012/4/4 Mehmet Zahir SOLAK <zahir...@gmail.com>

--
Halil Bozdoğan

[Yücel Kıvanç]

Selamlar,

VS 2010 un PowerCommands extensionında dosyayı her kaydettiğinde bunu
yapan bir özellik var:

http://visualstudiogallery.msdn.microsoft.com/e5f41ad9-4edc-4912-bca3-91147db95b99/

[Bayram Akbuz]

resharper alışması zor olabilir ama alıştıktan sonra da bırakması zor. resharper olmayan makinalarda bir eksiklik duyuyorum hep.

[Gokhan Demir]

Solution'da 300 tane projeniz mi var ?

2012/4/4 Halil Bozdogan <halilb...@gmail.com>

--
Gokhan Demir.

[Emre Mert Asyalıoğlu]

300 u bilmem ama bende 92 proje olan var :) sorun yok.. Icerigide orchard ve modulleri vs.

BlackBerry® Servisi ile gönderildi.

---

From: Gokhan Demir <yada...@gmail.com>

Sender: altdotne...@googlegroups.com

Date: Thu, 5 Apr 2012 16:18:47 +0300

To: <altdotne...@googlegroups.com>

ReplyTo: altdotne...@googlegroups.com

Subject: Re: [altdotnetturkiye] Organize Usings

[Halil Bozdogan]

Valla ben de de var 300 küsür projelik solution.

Bunun üzerinden çalışmıyoruz tabii, bu Global Solution dediğimiz bir olay, tüm herşey orada, ama biz ufak bölümler içinde (modüllerde) çalışıyoruz, onlarında kendi solution dosyaları var.

Bu arada CodeMaid kullansanıza ?

hem sayfayı kodu toparlıyor (indent felan) hem organize using yapıyor, hem analiz olmadığı için sistemi yormuyor, collapse all felan ve find in solution da geliyor ama hiç birini vs açılırken load olurken yapmıyor, sadece yapacağı zaman yapıyor :)

ek dosya felan da çıkarmıyor

2012/4/5 Gokhan Demir <yada...@gmail.com>

--
Halil Bozdoğan

[Erhan CAKIRMAN]

Benim bildigim 2 300 var biri spartalilar biride sizin solution J

 

p.s baba ne yaptiniz siz

 

From: altdotne...@googlegroups.com [mailto:altdotne...@googlegroups.com] On Behalf Of Halil Bozdogan
Sent: Thursday, April 05, 2012 4:51 PM
To: altdotne...@googlegroups.com
Subject: Re: [altdotnetturkiye] Organize Usings

 

Valla ben de de var 300 küsür projelik solution.

[Gokhan Demir]

solution compile surelerinizi merak ettim

2012/4/5 Emre Mert Asyalıoğlu <easya...@gmail.com>

--
Gokhan Demir.

[Hasan UZUN]

Biz projelerimizde NArrange kullaniyoruz.  Ucretsiz bir command-line araci. Visual Studio"da External Tools bolumune eklenip rahatlikla kullanilabilir. Kodun sekil semalini duzenliyor. Ayar dosyasi mevcut, ozellestirilebiliyor da. Basit ama kullanisli.

Hasan Uzun '04

2012/4/5 Erhan CAKIRMAN <ecak...@gmail.com>

[Sidar Ok]

300 Proje cok degil ana proje icin. Gunluk cali$malar icin her dakika bu solution i acmiyorlar zaten, buyk ihtimalle CI ve TFS icin kullaniyorlardir. 

2012/4/5 Hasan UZUN <hasa...@gmail.com>

[Emre Mert Asyalıoğlu]

20 - 25 sn civari.

BlackBerry® Servisi ile gönderildi.

---

From: Gokhan Demir <yada...@gmail.com>

Sender: altdotne...@googlegroups.com

Date: Thu, 5 Apr 2012 18:41:38 +0300

To: <altdotne...@googlegroups.com>

ReplyTo: altdotne...@googlegroups.com

Subject: Re: Ynt: Re: [altdotnetturkiye] Organize Usings

[Halil Bozdogan]

Aynen Sidar'ın dediği gibi,

 

CI için kullanıyoruz bu projeyi, 4 büyük projenin (Server, Client, Web ve Library) + 1 orta boyutta projenin birleştiği bir solution bu. biz X modül de çalışırken, çok alakasız bir yerde Web'de Y patlarsa diyebu dev solution ı açıp build etmiyoruz, CI gidiyor, dev solution da işlerini yapıyor, eğer patlarsa zaten söylüyor, patlamazsa sorun yok.

 

X içinde kendi özel solution da zorlasan 10-20 proje oluyor,  En aktif kullanılan iki solution Web ve Client ta ortalama 40 - 50 proje var ama onun da bazı projeleri aslında debug da kasmamak için Server app için eklenenler.

2012/4/5 Sidar Ok <sid...@gmail.com>

--
Halil Bozdoğan

[Sidar Ok]

Patlama i$ini CI  a birakmamak gerek gene de, surekli check in etmeden bir get latest yapmali. Gated Check-in de varsa build in integrity si guzel bi $ekilde korunmu$ oluyor zaten. 

Resharper in analizi hala cok yava$latiyor mu yaw ? 

2012/4/5 Halil Bozdogan <halilb...@gmail.com>

[Cengiz Han]

checkin yapmadan once CI da calisan scriptinizi aynen localde de calistirmaniz gerekli ki CI da fail ihtimali kalmasin. bunu yapmayan yerlerde genelde gordugum sorun, bahsedilen scriptin uzun surmesi ve developerlarin calistirmak ve beklemem istememesi. Bu zaten ayri bir smell oluyor, unit testler gercek unit test olmayabilir, integration pointlerde stubbed out serviceler kullanilabilir, vs. vs. 

Sormamda sakinca yok ise, sizin checkin den once tum projeyi derleyen/test eden CI scriptinizi localde de calistirmamanizin sebebi nedir? 

-- 

Cengiz Han

[Serdar KARAÇAY]

Solutionda 47 proje var (Asp.App,WinForms,Integration Services ve Reporting)

Build ve Debugging yaparken bütün projeleri yapmıyorum.

sadece StartUp projesini build ediyorum.

37 sn alıyor. :)

www.serdarkaracay.com | 0531 775 1659 | msn csha...@yahoo.com

5 Nisan 2012 18:41 tarihinde Gokhan Demir <yada...@gmail.com> yazdı:

[Serdar KARAÇAY]

CI nedir?Hangi kelimelerin kısa yazılışı :)

www.serdarkaracay.com | 0531 775 1659 | msn csha...@yahoo.com

6 Nisan 2012 03:47 tarihinde Cengiz Han <cen...@cengizhan.com> yazdı:

[ersin caliskan]

Continuous Integration.

Ersin Çalışkan

[emrem]

"CI faydaları, zararları nedir? Ne olursa CI yapmak mantıklı olur?" başlıklı farklı bir mail de bahsetsek mi?

6 Nisan 2012 09:14 tarihinde ersin caliskan <caliska...@gmail.com> yazdı:

[Barış Özaydın]

http://www.csharpnedir.com/articles/read/?id=561&title=S%C3%BCrekli%20T%C3%BCmle%C5%9Ftirme%20(Continuous%20Integration) şöyle bir şey var belki işine yarar.

2012/4/6 emrem <emr...@gmail.com>

--
Barış ÖZAYDIN...

[Sidar Ok]

CI in zararlari, balli sutun zararlari kadar :P 

2 ki$i ve fazlasinin cali$tigi her proje icin CI yapmak gerek. Hatta bazen tek ki$i de olabilir, integration yapilmasi gereken diger sistemler vs varsa.  

2012/4/6 Barış Özaydın <peac...@gmail.com>

[emrem]

neden süt bozuksa sonra balın şu sıralar hali manşetlik :) soruyu biraz daha değiştirip şöyle sormak daha iyi olacak sanırım. 

CI yapmayı gerektirecek hangi projelerde çalıştınız, önceden CI yapılmıyordu da sonra yapmaya başlayınca neler değişti ne faydası oldu gibi gibi. 

6 Nisan 2012 15:40 tarihinde Sidar Ok <sid...@gmail.com> yazdı:

[Doga Oztuzun]

Deployment icin harcanan sureyi kazanmak,

Eksik dosya ile yapilan commit ve fail olan build'i farkettirmesi, 

Unit testleri otomatik run etmesi, fail olan bir test, yine uyari verir.

..

2012/4/6 emrem <emr...@gmail.com>

--
http://www.DogaOztuzun.com/

[Emre Mert Asyalıoğlu]

Ek olarak;
Ne asamadayiz sorusuna ahanda bu linkten bak son build ve bundan sonraki tum gelismeler anlik olarak burada calisir durumda cevabi ni vermemize olanak saglar :) (kendi yazdigima sesli guldum ya :)

Bunun yaninda gelistirme asamasinda digerlerinin acaba gercekten isterlerim mi gelistiriliyorlar sorusuyla ici icini yiyen arkadaslar icin zahmetsiz olarak kontrol ortami olusturmasida cabasi :)

BlackBerry® Servisi ile gönderildi.

---

From: Doga Oztuzun <unq...@gmail.com>

Sender: altdotne...@googlegroups.com

Date: Fri, 6 Apr 2012 16:07:52 +0300

To: <altdotne...@googlegroups.com>

ReplyTo: altdotne...@googlegroups.com

[Halil Bozdogan]

@CengizHan İlk olarak öyle bir script yok, ayrıca, küçük solution'ları kendimiz build ediyoruz zaten, o konuda bir sıkıntı olmuyor ama dediğim gibi 4 farklı büyük entegre projeyi ne kadar script yazarsak yazalım, developer kendi makinesinde yapamaz. Yani benim makine 8gb, sunucudan hızlı işlemci var (Bir ssd yok onuda alacam bir ara kendim takacam artık) genede 4 projeyi ve bazı projelerin içindeki 3 deployment package çıkartmayı developer makinesine veremeyiz.

 

Genel olarak ta

 

CI geçişimiz aslında zor oldu, oluyor da, ama en temel sebep, build sırası oluşması ve bir şekilde developer için meşhur http://xkcd.com/303/ bahanesini, kişisel makinesinden almak :)

 

Bize tek zararı ise, CI oturacak derken, bir kaç gün boyunca, commit işlemlerini durdurmamız oldu.

2012/4/6 Doga Oztuzun <unq...@gmail.com>

--
Halil Bozdoğan

[Gokhan Demir]

Build scriptlerinin olmasi konusuna katiliyorum. Compile suresinin uzun olmasi proje sayisindan kaynaklaniyo sanirim.

Zamaninda "Separate Assemblies != Loose Coupling" temali guzel yazilar yazilmisti :

http://codebetter.com/jeremymiller/2008/09/30/separate-assemblies-loose-coupling/

http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio-solution-file/

http://geekswithblogs.net/FrostRed/archive/2008/10/03/125628.aspx

http://www.hanselman.com/blog/AssemblyFiefdomsWhatsTheRightNumberOfAssembliesLibraries.aspx

2012/4/8 Halil Bozdogan <halilb...@gmail.com>

--
Gokhan Demir.

[Sidar Ok]

Her zaman proje sayisinin fazlaligi loose coupling i garantilemek icin olmuyor, bazi projeler gercekten buyuk. 500 tane ayri makinada cali$an ayri servisi eglence olsun diye ayni projeye koymuyorlar insanlar :)

Paketlemenin bilinen en onemli kurallarindan biri : beraber degi$en $eyleri ayni pakete koymaktir. bu yuzden yumurtalarla portakallari beraber grupluyorlar, beraber yemek isteyenler icin daha efektif olsa bile. (Uncle bob un bi yazisi vardi bunla ilgili link bulmaya u$endim)

2012/4/9 Gokhan Demir <yada...@gmail.com>

[Gokhan Demir]

uncle bob'in yazisi : http://www.objectmentor.com/resources/articles/granularity.pdf 

@Sidar  buyuk projeler icersinde yer aldim ve israrla diyorum ki 300 proje ayni solution'un altinda ise biseyler yanlis dusunulmus. bir bankacilik projesini dusun,  bunun icersinde de bir cok servis/module olucaktir . credits, treasury, accounting vs hepsi kendi proje scopelarinda calisacak sekilde tasarlanmali. bu sayede hem maintainable bir structure olur hem de proje sayisi daha az tutulabilir. hepsini tek bir solution altina toplamak mantikli gelmiyor derken bunu kastediyorum.

 

2012/4/9 Sidar Ok <sid...@gmail.com>

--
Gokhan Demir.

[Berke Sokhan]

Selamlar, 

Ben de 300 tane projenin aynı solution'da olmasını mimari olarak bir sıkıntı yaratabileceğini düşünüyorum. Bu adamların birbirlerine ref'leri olmayabilir, ama o zaman neden yanyanalar? CI yeterince iyi bir sebep değil, CI build konfigurasyonunda ayarlanabilir dependencyler.

QCon London 2012'de bununla ilgili Stefan Tilkov'ın güzel bir anlatımı vardı, Breaking the monolith: Towards a system-of-systems architecture (http://qconlondon.com/london-2012/schedule/wednesday.jsp linkinden schedule'da bulup (ARCHITECTURE EVOLUTION AND IMPROVEMENT tracki) "Download Slides" derseniz sunuma ulaşabilirsiniz.)

QCon boyunca gördüğün kadarıyla bir çok mimar/developerın görüşü büyük projeler daha başlarken birden fazla sistemden oluşacağını varsayıp entegrasyonu, hatta veri çoklamayı bile göze almanız. Yani projelerinizi bölmeniz.

CI buildleri için durum farklı olabilir, ama o da CI build sisteminizin bir başarısı (başarısızlığı?) olarak değerlendirilebilir.

9 Nisan 2012 11:02 tarihinde Gokhan Demir <yada...@gmail.com> yazdı:

--
Berke SOKHAN.

http://twitter.com/berkesokhan
http://blog.berkesokhan.com
http://www.birliktegelistir.com/editors.aspx

[Sidar Ok]

Cok buyuk projelerde yer almi$sin ama demek ki yeteri kadar buyuklerinde yer almami$sin :)  

Butun cozumler "silo" dedigimiz kendi ba$ina cali$an projelerden ibaret degiller. Departman seviyesinde modularite & granularite cali$malari ba$arili olabilirken enterprise seviyesindeki stratejik projelerde development in baktigi moduler baki$ mumkun olmayabiliyor.

Ayrica butun cozumler de greenfield degil, legacy leri dikkate alarak geli$tirmen gereken mimari yapilar greenfield lardan daha fazla oluyor.   

Ornegi vermi$tim aslinda, gercek hayattan bir ornek : Sadece 728 tane public service (kimi web kimi binary) var, Avrupanin en buyuk Telecom Operatoru. Hepsi farkli server lara deploy edilebiliyor,kimi var tum server lara deploy ediliyor.  Kac tane teknik, internal servis var saymiyorum bile. Hatta bu service lerin data layer larini, business layer larini da saymiyorum.  Yani dll sayisini, proje sayisini azaltmanin imkani yok. 

Bunlari kullanan web application lar, windows application lar in hepsi de ayri solution larda, onlar da dert degil. 

$imdi bu servislerin hepsi bir solution da. Bunlarin hepsinin birbirini direkt kullanma ihtimali var, butun sistem loosely coupled degil (aci gercekler). Biri degi$tiginde diger hepsinin build ve test edilmesi gerek. Hepsi kritik servisler, %99.99  uptime requirement lari var. Bircok lari da mission critical. Unit testlerin yani sira bircok integration test var, olmak da zorunda. Testlerden  bazilari kendi virtual machine lerini yaratiyor, bazilari stress testi bazilari 

Ha, $imdi farkli projelere bolup CI i optimize de edebilirsin, bir build script de diger solution larin build script lerini cagirabilirsin vs. ama bu yukun altindan kalkamazsin. O zaman da bir solution yerine bircok solution olmu$ olur ama gene bir build script olur diger build script leri kapsayan, ve kendimizi kandirmi$ oluruz sadece, sln dosyasi yerine script dosyalarina dependant olmu$ oluruz. 

Beraber degi$en $eyleri ayni pakete koyalim, ama beraber degi$en $eylerin sayisi cok olabiliyor maalesef. 

Developer lar buyuk projeyi acip orada kod yaziyorlar mi ? Yazmiyorlar tabi, kendi kucuk sln leri var. 

2012/4/9 Gokhan Demir <yada...@gmail.com>

[onur eker]

Merhaba uzun süreden sonra "tekrar ve ancak" okuyabildiğim için mailleri, maalesef yeni gördüm bu konuyu :)

Yeteri kadar büyük projelerde yer almışsın ama yeteri kadar loosely coupled değillermiş :)

Solution yapısının doğru kurulabilmesi; proje kapsamının büyük olmasından öte, sistemin  loosely coupled olarak tasarlanması ile alakalı bir durum.

Şuan çalıştığım firmadaki sistem kapsamını anlatmak için rakamları kullanmak iyi olacak :)

* Sistem birbiri ile bağlantılı modüllerden oluşmakta ve bu modüller Gökhan'ın da belirttiği gibi, muhasebe, müşteri, kredi, vs... modülleri. Modül sayısı ise 500+

* Servis sayısı 27000+, modüllere dağılmış olan bu servisler tabi ki kesintisiz hizmet vermek zorunda ve servis availability min %99 olmalı. Şunu da belirtmek gerek, 2 sn üzerinde cevap veren bir servis unavailable olarak değerlendiriliyor!

* Her ay, sistem performans değerlendirilmesi yapılıyor, ve her gün istatistiki bilgiler ile sistem devamlı olarak inceleniyor.

Yanlış bir kanı vermemek için sistemin java ile yazıldığını da belirtmek gerek tabi, fakat tabi ki "sln" uzantılı olmasa da kullanılan ide'nin de bir solution mantığı var :)

Sonuç;

Sistem modüller bazında build ediliyor ve developerlar yine modüller bazında geliştirme yapıyorlar.

Fakat bunun yapılabilmesine imkan veren tek şey modüllerin az veya çok olması değil, modüllerin ve alt yapının "loosely coupled" olarak tasarlanmış olması.

2012/4/9 Sidar Ok <sid...@gmail.com>