front end ^*

• ingilizcede on yuz, on son, on hede. arkasini gormenin; nesnel, duyulara dayanan bir kavramadan daha genis bir anlamda zor oldugu hallerde onyuz'e verilen isim.
• linuxta genelde konsol programlari icin sonradan yazilan grafik arayuzlere verilen ad. siz grafik ortamda ayarlari yaparsiniz front end de gerekli parametrelerle konsol programini calistirir
• bir lp yada cd deki sinyal kaynağını ifade eder.ayrıca tunerde sinyali antenden alıp modüle eden devre katı içinde kullanılır.
• compiler'lar soz konusu oldugunda kodun parse edilmesinden compiler tarafindan memory'de internal veri yapisi icerisine yerlestirilmesine kadar olan islerden sorumlu kisim.
  (bkz: back end)
• genel olarak yazılım sistemlerinde, verinin kaynaktan alınmasını sağlayan yazılım bileşeni diye tanımlamak akademik olarak da doğru olur sanırım.
  
  buna göre, bir kelime işlemcisinin front-end'i gui'si diyebiliriz.
  
  client-server mimari üzerinde inşa edilmiş bir m2m ağında ise web socket bileşenleri front-end olarak adlandırılabilir.
  
  her iki örnekte de, front end dediğimiz kısım, esas ilgimiz olan verinin (key strokes, tcp paketi) kullanıcıdan (insan, sensör) hedefe (harddisk, file server) gideceği yolun ilk bileşeni olmuş oluyor.
• bir bilgisayar programında kullanıcının/müşterinin direkt olarak ilişki içinde olacağı bölümdür. örneğin front-end için geliştirme yapan bir yazılımcı kullanıcı için önyüzü ve fonksiyonlarını tasarlar. back-end için geliştirme yapan arkadaş da kullanıcının yaptıklarının sistem, veritabanı düzeyindeki etkilerini geliştirir.
• yazılım sektöründe ön yüz denilen yani son kullanıcının gördüğü görselliği sağlayan yazılım geliştiricilere verilen ünvan.
  
  genellikle web sektöründe yaygın olarak görev almaktadırlar. front-end developer olarak title almaktadırlar. title kademeleri ise junior, senior ve architect olarak ayrılmaktadır.
• web gelistirme acisindan düsünüldügünde cogunlukla html, css ve javascript dil ve/veya teknolojilerini icine alan "client side" yani kullanici tarafli uygulanmasidir ve bu tarafta yapilan web gelistirmesine "front-end development" adi verilir. back-end gelistirme ile karsilastirildiginda genel olarak ikisinde de yazilim gelistirme methodlarina bagli kalinsa da öncelikler birinden digerine degisir. örnegin front-end gelistirme daha cok kullanici tarafindan tetiklenen "event" yani olaylar belirleyici olurken back-end gelistirmede data ve data yapisi daha belirleyicidir. bu nedenledir ki back-end yapilarinin diagram haline getirilmesinde uml diagramlarindan "entity relationship" diagram olayin bütününü görmek icin bize bircok ipucu verirken, front-end gelistirmede "entitiy relationship" diagram tarafindan verilen bilgi biraz ciliz kalmakta, onun yerine "action diagram" dan daha cok ipucu elde etmemiz mümkündür. kisisel deneyimlerime göre iki taraftan baktigimda back-end ve front-end gelistiricilerin kafa ve mantik yapilari da birbirinden farklilik göstermektedirler. back-end gelistiriciler öncelikli olarak genel yapiya mimariye sadik kalma taraftari olduklarini düsünmekteyim. bunun sonucu olarak da yazilan her methodun, sinifin sinirlari belli, daha iyi ve düsünülerek "encapsulation" yapilmis, "inheritance" daha detayli düsünülerek olusuturulmus oluyor. bu sayede back-end yapilarinin daha modüler oldugunu, ve uygulamanin daha cok genisletilebilir "extendible" ve tekrardan kullanilabilir "re-usable" oldugunu düsünüyorum. ama front-end tarafinda gectigimizde gelistiriciler daha cok sonuc odaklilar ve yapidan cok aksiyonunun sonuclandirilip kullaniciya uygun datanin ve "view" görünümün saglanmasina odaklilar. bu da fonksiyonlar ve siniflar arasi erisimin daha esnek tutulmasina neden oluyor yani bir sinifa ait data veya özellik her yerden rahatlikla erisilebilir olarak tasarlanmasina neden oluyor. bu tarz gelistirme uygulamanin daha cok "statefull" olmasi sonucu doguruyor. "stateful" uygulamalarda yapilan degisikliklerin uygulamanin baska yerinde istenmeyen yan etkilere neden olmasi "stateless" uygulamalardan cok daha fazla, ve hata ayiklamanin daha zor bir sürec olmasi aslinda genelde daha cok zaman kaybina neden oldugunu ve verimsiz oldugunu düsünüyorum. yine bu sekilde yapinin daha cok istenmeyen "spagetti code" üretmeye yönelttigini, hele bir de gelistirme sürecine birden fazla gelistirici dahil oldugunda ve uygulama büyüdükce "re-factoring" ihtiyacinin giderek arttigini düsünmekteyim. bu nedenle nihai olarak fron-end gelistiriciler sonuc odakli ve hizli sonuc cikartsalar da uygulamanin hacmi genisledikce aslinda üretkenliklerinin "gelistir - test et - ekleme yap - test et - refactoring - test et" döngüsünde daha fazla "iteration" yani yinelemeye neden oldugu ve verimsizlestigi gözüküyor. bu sebeple front-end gelistiricilerin mvc yapisina sadik kalinmasi yanlislikla da olsa kötü kod yaziminin engellenyen sinirlamalarin konulmasini saglayacak ve gelistirici icin bir nevi kerteriz noktasi olacaktir.
• frontend istanbul grubu developer'ların maaşları, çalıştıkları şirket türleri ve mezuniyetleriyle ilgili mini bir anket düzenlenmiş. ankete göre en fazla kazanılan para ortalama 8.9 bin tl. en çok çalışılan şirket türü %47,5ile kurumsal firmalar, çalışanların %60'ysa üniversite mezunu.
  
  https://twitter.com/…bul/status/1088430645808951296
• web sitesinde kullanıcıların gördüğü kısma denir.