Cihazda safari ve uygulamada kullandığımız webview içeriğinin bilgisayar üzerinden debug edilmesi.
Webview kullanılan projelerde sayfaları ve JavaScriptleri debug ederek web sayfasındaki hataları giderebilmekteyiz. Bunun için cihazı bilgisayarınıza bağlamanız ve tarayıcınızın geliştirici ayarlarını kullanmanız gerekmektedir.
iOS webviewde web sayfasındaki console.log() mesajları Xcode log’larında görüntülenememektedir. Bunun için Safari’nin geliştirici ayarlarını kullanarak kolaylıkla log’ları ve hata ayıklamalarını yapabilmekteyiz.
Bu sınırlamaları göz önünde bulundurarak, iOS’ta bir web görünümünde uzaktan hata ayıklama adımları şunlardır:
2. Ardından, geliştirmeyi yaptığınız bilgisayarınızda Safari’de geliştirici araçlarını da etkinleştirmelisiniz. Geliştirme bilgisayarınızda Safari’yi başlatın ve menü çubuğunda Safari > Preferences (Safari > Tercihler’e) gidin. Görüntülenen tercihler bölmesinde, Gelişmiş sekmesine tıklayın ve ardından alttaki Show Develop (Geliştirmeyi Göster) menü seçeneğini etkinleştirin. Bunu yaptıktan sonra tercihler bölmesini kapatabilirsiniz.
3. iOS cihazınızı geliştirici bilgisayarınıza bağlayın ve uygulamanızı veya safari başlatın.
4. Geliştirici bilgisayarınızdaki Safari’de, menü çubuğunda Develop (Geliştir’e) tıklayın ve iOS cihazınızda çalışan webview örneklerinin bir listesini göstermek için iOS cihazınızın adını seçin.
5. Hatalarını ayıklamak istediğiniz web görünümü için açılır seçeneği tıklayın. Bu, web görünümünü incelemek için yeni bir Safari Web Denetçisi penceresi açacaktır.
Author: Atakan Cengiz Kurt
In this article, I will discuss the details and differences of using Build Types and Product Flavors in Android. Both structures provide many conveniences when creating Android applications. We can benefit from many points, from the icons of the applications to the production versions, and from special configurations for development mode to creating different variants of the application.
Build Types help us customize certain features used by Gradle when developing, building, and preparing signed versions of applications. They also make it easier for us to manage certain configurations that we will use. By default, two Build Types are defined in newly created Android projects: one is the debug mode, and the other is the release mode.
We can add a new type. Based on the types, we can add different version extensions or completely custom variables. During development, you can easily switch between these different types using the Build Variants tab located at the bottom left of Android Studio as a shortcut.
In the code example below, the MODE variable will be updated based on the selected type in the automatically created BuildConfig.java class after the code is compiled for the first time. You can easily access these static variables within code blocks. You can also apply your environment changes here. Thanks to this flexibility, you can set up a more secure and flexible development environment using special configurations for the development mode.
buildTypes {
debug {
signingConfig signingConfigs.debug
shrinkResources false
minifyEnabled = false
debuggable true
resValue "string", "google_maps_key", (project.findProperty("GOOGLE_MAPS_API_KEY_DEBUG") ?: "")
buildConfigField "MODE", "DEBUG"
ext.betaDistributionReleaseNotesFilePath = "release_notes.txt"
ext.betaDistributionEmailsFilePath = "testers.txt"
ndk {
abiFilters "x86", "armeabi-v7a", "arm64-v8a"
}
}
release {
signingConfig signingConfigs.release
shrinkResources true
minifyEnabled true
debuggable false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
resValue "string", "google_maps_key", (project.findProperty("GOOGLE_MAPS_API_KEY") ?: "")
buildConfigField "MODE", "PROD"
ext.betaDistributionReleaseNotesFilePath = "release_notes.txt"
ext.betaDistributionEmailsFilePath = "testers.txt"
ndk {
abiFilters "armeabi-v7a", "arm64-v8a"
}
}
pilot {
debuggable = true
signingConfig signingConfigs.debug
debuggable true
resValue "string", "google_maps_key", (project.findProperty("GOOGLE_MAPS_API_KEY") ?: "")
ext.betaDistributionReleaseNotesFilePath = "release_notes.txt"
ext.betaDistributionEmailsFilePath = "testers.txt"
buildConfigField "MODE", "PILOT"
ndk {
abiFilters "x86", "armeabi-v7a", "arm64-v8a"
}
}
}
Product Flavors is a structure similar to Build Types that provides flexibility. The main difference is that it allows us to generate different versions of the application from a shared codebase.
Android Product Flavors are used to create different versions of an app. These versions can have different features, such as being free or paid, having different themes and texts, or using different environments or APIs. For example, you want to create both a paid and a free version of the same app, with only minor differences between the two. Instead of using a separate codebase for each app, you can use the Product Flavors structure to create multiple versions using a shared codebase. With Product Flavors, you can easily manage many features of the app, from the name to the icon, version information to the API environment to be used.
flavorDimensions "env", "api"
productFlavors {
prod {
dimension "env"
resValue "string", "app_name", '"Production"'
manifestPlaceholders = [
appIcon: "@mipmap/ic_launcher",
appIconRound: "@mipmap/ic_launcher_round"
]
applicationIdSuffix ".release"
buildConfigField "String", "FLAVOR_TYPE", '"PRODUCTION"'
buildConfigField "String", "DATABASE", '"PRODUCTION_DB"'
}
test {
dimension "env"
resValue "string", "app_name", '"Test"'
manifestPlaceholders = [
appIcon: "@mipmap/ic_launcher_test",
appIconRound: "@mipmap/ic_launcher_test_round"
]
applicationIdSuffix ".test"
buildConfigField "String", "FLAVOR_TYPE", '"test"'
buildConfigField "String", "DATABASE", '"TEST_DB"'
}
minApi28 {
dimension "api"
minSdkVersion 23
versionCode 10000 + defaultConfig.versionCode
versionNameSuffix "-minApi28"
}
minApi24 {
dimension "api"
minSdkVersion 21
versionCode 10000 + defaultConfig.versionCode
versionNameSuffix "-minApi24"
}
}
I have a few points that I’d like to explain about the code block I shared above. Firstly, I have defined two dimensions with Flavor Dimensions: one is “env” and the other is “api”. With this feature, we can group based on these dimensions and use their combinations. That is, when we first compile the build.gradle by adding the code block above, the result of the combination between the “env” and “api” groups will appear in the Build Variants tab. You can see the output of this in the image below. For example, we get a new variant version by combining the test variant with the Minimum Api 24 variant. This way, we can make separate arrangements for APIs 24 and 28 with the same codebase, and distribute and manage them separately. We can make the names of the applications different from each other with “res_value” parameter. With “manifest placeholders” parameter, we can also use the application icons in different ways. Changing the app name with manifest placeholders is also possible.
Product Flavors structure also allows you to define custom variables in the same way as the Build Types structure. Similarly, you can access these static variables through the BuildConfig.java class
Author: Erdi Koç
Günümüzde kurumsal firmaların büyük bir çoğunluğu teknolojik alt yapısını bulut servislerine emanet etmiş durumda. Öyle ki, gelinen son noktada bulut servisleri On-Prime yapıların sağladığı tüm hizmetleri sağlar duruma geldi. Bununla beraber Bulut Sağlayıcı (Microsoft, Amazon, Google) firmaların girdiği rekabet dolayısıyla her geçen gün daha ekonomik seçeneklerle karşımıza çıkan bu servisler, kullanıcının sunulan hizmete ne kadar müdahale edebildiği veya ne kadar sorumlu olduğuna bağlı olarak 3 farklı kategoriye ayrılmış durumdadır.
Bunlar sırasıyla IaaS , PaaS ve SaaS olarak isimlendirilmektedir.
IaaS yani “Altyapı olarak hizmet” anlayışı, on-prime yapıların bir adım ötesi olarak düşünülebilir. On-prime sistemlerden farklı olarak, ağ(network), donanım, sanallaştırma gibi katmanlardan arındırılmış olarak doğrudan işletim sistemi seviyesinde hizmet sağlanır. Örnek olarak sanal makine kiralamak gösterilebilir. Bulut servislerindeki diğer hizmet türleri (Paas,Saas) ile karşılaştırıldığında, kullanıcıya en fazla yetki ve sorumluluğun tanımlandığı seçenek olduğunu söyleyebiliriz.
Iaas Hizmetlere Örnekler :
Kullanıcı sadece Uygulama ve Veri katmanından sorumludur. İşletim sistemi bazında herhangi bir sorumluluğunuz olmaz. Herhangi bir web veya mobil uygulamayı ayağa kaldırmak ve yönetmek için kullanılabilir. PaaS hizmetler genellikle yazılım geliştiriciler tarafından, uygulamaya daha fazla odaklanmak ve uygulamayı ayağa kaldırmak için gerekli olan alt yapı işlerinin yükünden kurtulmak için tercih edilir. Aşağıdaki servislerde genellikle web veya mobil tabanlı uygulamaların hızlı bir şekilde geliştirilmesi için gerekli ortamı sağlamaktadır.
Paas Hizmetlere Örnekler :
Hizmet olarak doğrudan uygulamanın sunulmasıdır. Genellikle uygulamaya tarayıcı üzerinden ulaşılır ve kullanıcılar çeşitli abonelik yöntemleri ile bu uygulamaları satın alır. Saas hizmet sağlayıcıları, uygulama ile ilgili tüm bakım, geliştirme ve güvenlik konularında sorumluluk sahibidir.
Saas Hizmetlere Örnekler :
IaaS,PaaS ve SaaS hizmet türleri, bulut teknolojilerindeki 3 ana kategori olarak adlandırılabilir ancak gelişen teknoloji ve değişen ihtiyaçlar neticesinde bu 3 hizmet türünden daha farklı seçenekler de doğmaya devam ediyor. Tüm bu gelişmelerden haberdar olmak ve incelemek için takipte kalın!
Görüşmek üzere!
Author: Deniz Alkan
Azure servisleri üzerinde SQL bir veri tabanına sahip olmanın 3 farklı seçeneği bulunmaktadır. Bu seçenekler, tam olarak ihtiyaç duyduğunuz hizmeti alma ve sadece aldığınız hizmet kadar ödeme yapma şansı sunmaktadır. Şimdi hep beraber Azure SQL dağıtım seçeneklerini inceleyelim.
SQL Sanal makineleri, kullanıcının SQL Server üzerinde en çok yetki ve sorumluluğa sahip olduğu seçenektir. Bu seçenekteki hizmet türü IASS (Infastructure as a Service) yani sadece alt yapı sağlayan bir hizmet türü olduğundan, Sanal makinedeki işletim sistemi güncellemeleri ve SQL Server üzerindeki güvenlik yamaları dışındaki tüm işlemler, kullanıcının sorumluluğundadır. Elbette bu sorumluluk kullanıcıya çok daha geniş bir yetki alanı tanımış oluyor. Öyle ki, SQL Server hizmetinin tamamını konfigure edebildiğiniz için SQL Veritabanı hizmetinin yanında SSAS, SSRS ve SSIS gibi yardımcı servislerinde kurulumu yaparak bu servisleri kullanabilirsiniz.
Türkçesi kulağa biraz garip geliyor olabilir. O yüzden biz İngilizce haline odaklanalım, Managed Instance! Bildiğiniz üzere SQL Server kurulumu yaparken birden fazla Instance oluşturabilirsiniz. Bir önceki seçenekte olduğu gibi sanal bir makine üzerinde SQL Server kurulumu yaparsanız birden fazla Instance’a sahip olabilirsiniz. Managed Instance seçeneğinde ise Azure sizlere SQL Server üzerinde kurulmuş bir adet Instance hizmeti sağlar. Bu servisin hizmet türü de PAAS (Platform as a Service) olarak adlandırılmaktadır. Yani alt yapıdan daha fazlasını sunan bir hizmet türüdür. SQL Server platformunu hizmet olarak sağlar. Bu durumda sorumluluğunuz daha az dolayısıyla hareket alanınız da daha kısıtlıdır. Managed Instance hizmeti ile SQL Server Agent, Machine Learning Services, CLR ve SSIS gibi servisleri kullanabilirsiniz.
SQL Veritabanı, kullanıcıları hem işletim sisteminden hem de SQL Server yapısından soyutlamaktadır. Bu seçenek size sadece SQL Veritabanı hizmeti sağlar. Instance bazında herhangi bir değişiklik veya kurulum yapma yetkiniz bulunmaz. Yetki alanının daha dar olmasına rağmen, SQL Veritabanı hizmeti, sınırsız depolama alanı ve otomatik ölçeklendirme gibi ihtiyaçları karşılayan tek dağıtım seçeneğidir. Ek olarak SQL Veritabanı servisinin de hizmet türü PAAS olarak sınıflandırılmaktadır.
Görüldüğü üzere her bir dağıtım seçeneğinin birbirine göre avantajlı veya dezavantajlı olduğu durumlar mevcut. Siz de ihtiyaçlarınıza en uygun dağıtımı seçerek Azure dünyasına adımınızı atabilirsiniz.
Bulut teknolojileri üzerinde kullandığımız servisler, sunulan hizmetin ne kadarının sistem tarafından, ne kadarının kullanıcı tarafından yönetildiğine bağlı olarak farklı kategorilere ayrılır. Bunlar sırasıyla IASS , PAAS ve SAAS olarak isimlendirilir.
Bu kategorileri detaylı incelemek için aşağıdaki yazıya göz atabilirsiniz.
Daha detaylı incelemeler için takipte kalın!
Görüşmek üzere!
Kaynakça :
Author: Deniz Alkan
There are several ways to style react app. Each one has its own pros and cons. In this article, I’ll show you ways of using stylings and what is the best option.
“If you tell yourself you can’t, you won’t.” -Dean Graziosi
I’ll mention primary ways to style a react app. There is a number one option in this, for me. When choosing a way, we must consider two crucial topics; Firstly every project has different needs. Secondly, developers; whose the main characters of the software. We should consider developers’ skillsets, the project’s future, etc. Long story short all these things should be evaluated wisely.
Let’s start.
— INLINE STYLING
This is the most basic option. It’s just like coding HTML. Styling elements inline doesn’t require you to create a separate stylesheet.
PROS 👍🏻
CONS 👎🏻
If the app will be very small maybe you can select, otherwise you shound’t select this option. I think.
— PLAIN CSS
This way is the most common approach. It’s easy to use and understandable. Write CSS in another file and import it to style a component’s element.
PROS 👍🏻
CONS 👎🏻
This option can be selectable. But if you define the project as big, skip this.
— SASS / SCSS
SASS is a preprocessor for CSS. Stylesheets are getting larger, more complex, and harder to maintain. This is where a preprocessor can help. Sass has features that don’t exist in CSS yet like nesting, mixins, inheritance, and other nifty goodies that help you write robust, maintainable CSS.
PROS 👍🏻
CONS 👎🏻
— CSS MODULES
This one is actually an alternative to the last two options (Css,scss). Everything is the same but by using this our CSS codes will be scoped.
It has a simple usage. Let’s say you have a file named Home.jsx, create another file here and give a name as Home.module.scss. And simply import this file to Home.jsx.
By using this our classnames will be unique.
Naming style: fileName_className__[unique_identifier]. Example:
<div class="Home_home__9Ke73">
PROS 👍🏻
CONS 👎🏻
For multiple and conditional classnames can be use classnames.
— CSS in JS
You can write CSS in the react file, like HTML. React made this possible. These codes will be scoped too, obviously.
Usage example:
import styled from "styled-components";
const Button = styled.button`
color: limegreen;
border: 2px solid limegreen;
margin: 1em;
padding: 0.25em 1em;
border-radius: 3px;
`;
PROS 👍🏻
CONS 👎🏻
— USING A THIRD-PARTY LIBRARY
There are many CSS libraries and pre-made components out there. Like tailwind, bootstrap, chakraUI, and materialUI. Using there may be easier compared to others.
PROS 👍🏻
CONS 👎🏻
What am I using?
I usually use CSS modules with SCSS. Because this meets all my requests, easy and common.
Firstly I’m creating a styles folder in assets and creating global files in it like animations, global, mixins, and variables. After that, I combine these in main.scss file and in index.css refer it with import.
By the way, I have a folder structure article. If you wanna read, you can simply click the following link.
And every other file has a .module.scss file. This way I kept the advantages of multiple options.
I mentioned nearly every possible way to style react app. Every option has pros and cons. Choosing may be tough. But like I said before, must be evaluated wisely.
I hope this guide helps you.
Author: Mahir Uslu
İlk paylaşımım olan bu yazımda React’ın memoization hooklarından useMemo ve useCallback’i ele almak istedim. Birçok kişide kafa karışıklığına neden olan, nerede ve nasıl kullanılması gerektiğinden emin olunamayan bu hookları örnekleri ile birlikte açıklayacağım.
Eğer orta veya büyük ölçekli React projelerinde görev alıyorsanız bu hooklar ile büyük ihtimalle karşılaşmışsınızdır. Hatta tam olarak işlevlerini bilmeden projede kullanılıyor diye kullanmış da olabilirsiniz fakat bu kullanımların çoğunun gereksiz ve memory leak’lere neden olduğunu söylemem gerekir. Lafı daha fazla uzatmadan useMemo ile useCallback’ten ve asıl kullanım amaçlarından bahsedelim.
Memory Leak: Kodların kullanmış olduğu hafıza bloğu ile işinin sona ermesine rağmen o hafıza bloğunu bırakmamasına denir.
Örnekte de gözüktüğü şekilde useMemo, bir “create” fonksiyonu ile dependency array (bağımlı değişkenler dizisi) alır ve bir memoized value (hafızaya alınmış değer) dönüşü yapar. Örnekteki isimlendirmelerle devam edecek olursak memoizedValue değişkeni, dependency array içerisindeki a veya b değerleri değişmediği sürece aynı değeri hafızada tutacaktır. Eğer a veya b değerlerinden en az birisi değişirse “create” fonksiyonu çalışıp yeni bir değer dönüşü yapacaktır. Hesaplanması zaman alabilecek ve performans sorunlarına neden olacak değerleri hesaplamak için kullanılır (computationally expensive calculations).
useCallback ise argüman olarak inline callback ile dependency array alır ve dönüş değeri olarak da memoized callback (hafızaya alınmış callback fonksiyonu) dönüşü yapar. useMemo’da da olduğu gibi memoizedCallback değişkeninin tutuğu callback sadece dependency array içerisindeki a veya b değişkenleri değiştiği zaman değişir. Ayrıca useCallback, gereksiz render etme işlemlerini önlemek için reference equality yöntemine göre optimize edilmiş alt componentlere callback fonksiyonu geçerken işimize yarar.
useMemo ve useCallback gibi memoization hooklarını kullanmak maliyet doğurabilir. Bu yüzden gerçekten ihtiyaç duyulan noktalarda sorumluluk alınarak kullanılması gerekmektedir.
JavaScript dilinde abstract equality (==) ve strict equality (===) olarak iki çeşit eşitlik operatörü vardır. React ise genellikle Object.is(object1, object2) eşitlik kontrolünü kullanır fakat çok detaya girmeden bu yapı ile strict equality’nin oldukça benzer olduğunu söyleyebiliriz.
React’ta referential equalty’nin önemli olduğu 2 durum vardır. Bunlardan biri dependency array diğeri ise React.memo’dur.
Dependency Array
React’ta ki bazı hooklar, yapısında dependency array bulundurur. Bunlardan en bilindikleri ise useEffect, useMemo ve useCallback şeklinde sıralanabilir. useEffect üzerinden örnekler ile devam edecek olursak (örnekler anlaşılır olması için basit tutulmuştur):
Yukarıdaki örnekte firstProp ile secondProp değiştiğinde useEffect’in tetiklenmesi amaçlanıp functionA’nın tekrar çalıştırılması beklenmektedir. Fakat JavaScript’in çalışma mantığı nedeniyle propObject her render sonrasında yenilenecektir. Bu nedenle de React, useEffect’in dependency array’inde bulunan değişkenin değiştiğini düşünüp firstProp ve secondProp değişmemiş olsa da useEffect’i çalıştıracaktır. Bu yüzden istenmeyen durumlar oluşabilmektedir ve iki farklı şekilde bu durumu düzeltmemiz mümkündür.
Bunlardan ilki ve mümkünse uygulanmasını tavsiye edeceğim çözüm yolu şu şekildedir.
Fakat bazı durumlarda geçtiğimiz proplar primitive (string, number vb.) olmayabilir. Yani function, object veya array gibi tiplere sahip olduklarında useMemo veya useCallback kullanarak yukarıda bahsettiğimiz sorunu düzeltebiliriz.
Bu kullanım şekli de aslında useMemo ve useCallback hooklarının ortaya çıkış nedenini göstermektedir.
React.memo
Yine bir örnek üzerinden ilerleyecek olursak:
Örnekte de gözüktüğü üzere Counter komponentimiz, Button adlarında iki adet komponent barındırmaktadır. Button komponentlerinden birine her tıkladığımızda Counter komponenti içerisindeki statelerden biri değişeceği için her iki Button komponenti de render edilecektir. Tıklamış olduğumuz yani değerinin değişmesini istediğimiz Button komponentinin içerisinde güncel count değerine ulaşacağımız için bu komponentin render olması bize bir sorun teşkil etmezken diğer Button komponenti gereksiz bir şekilde tekrar render edilecektir. Bu sorunu düzeltmek için Button komponentini React.memo ile sarmalamamız gerekmektedir.
React.memo(component, areEqual) aslında bir high order component’dir (üst katman bileşeni) ve gözüktüğü şekilde 2 adet argüman alır. İlk argüman sarmalamak istediğimiz komponent olurken ikinci argümanı ise kullanılması zorunlu olmayan özel karşılaştırma (areEqual) fonksiyonudur. Ayrıca React.memo normalde yüzeysel olarak (shallowly compare) komponent içerisindeki propları karşılaştırıp render işlemine karar verirken areEqual fonksiyonu sayesinde karşılaştırma işlemini özelleştirebiliriz. Detaylı bilgi için…
Yukarıdaki şekilde sarmaladıktan sonra Button komponenti React.memo sayesinde sadece propları değiştiği zaman tekrar render edilecektir. Tam da burada küçük bir noktayı daha düzeltmemiz gerekiyor çünkü Button komponentinin proplarından onClick’e verilen değişkenler non-primitive (function, object vb.) tipte olduğu için state değişiminden sonra yeniden oluşturulacaklar ve gereksiz render etme işlemini önleyememiş olacağız. Bu durumu düzeltmek için de devreye useCallback’i giriyor (duruma göre useMemo da kullanılabilir).
Yaptığımız bu değişiklik ile gereksiz render etme işlemini önlemiş oluyor ve React.memo’yu sağlıklı bir şekilde kullanmış oluyoruz.
React.memo optimizasyonu bir maliyet doğurabileceğinden dolayı kullanımına karar vermeden önce emin olmalıyız ve doğru bir şekilde kullanmalıyız. Ayrıca React’ın hızlı çalışma yapısı sayesinde ciddi sorunlar çıkarmayan gereksiz render işlemleri göz ardı edilebilir.
Maliyet doğurabilecek hesaplamaları useMemo içerisinde yapmak bize performans sağlayacaktır. useMemo’nun asıl ortaya çıkış amacı da bu tarz maliyetli işlemleri gereksiz tekrarlardan sakınmak içindir. Yine bir örnek verecek olursak (tam olarak kullanışlı bir senaryo olmasa da anlaşılır olmasını amaçladığım bir örnek):
Yukarıdaki kod satırlarında gözüktüğü şekilde olası render işlemlerinde calculatePrimes tekrar tekrar çalışacaktır ve asal sayıların hesaplanmasının maliyet oluşturacağını varsayarsak projemize ciddi bir yük olacaktır.
Bu şekilde useMemo ile sarmaladığımızda sadece dependency array içerisindeki değerlerin değişmesi durumda hesaplanacaktır. Yani gereksiz render işlemlerinde hesaplama yapmayıp hafızadaki hesaplanmış değeri döndürecektir.
useMemo ve useCallback hooklarının kullanımı performans sağlayabilirken maliyetinin de olabileceğini tekrar vurgulamak istiyorum. Özellikle aynı proje üzerinde çalıştığınız arkadaşlarınız için karışıklık doğurabilir ya da dependency array’de yapacağınız yanlışlık ile memoize edilmiş değerlerin garbage collector tarafından temizlenmesini engelleyerek performans sorunlarına neden olabilirsiniz. Eğer ölçümlerinizi ve kullanımınızı doğru yaparsanız başta da söylediğim gibi performans faydaları sağlayabilirsiniz.
Umarım faydalı bir yazı olmuştur 🙂
Author: Mehmet Mutlu
The folder structure matters in many ways; it eases understanding, refactoring, and sustainability. In this article, I’ll show how we should manage our react app’s folder struct.
“If you have the guts to keep making mistakes, your wisdom and intelligence leap forward with huge momentum.” -Holly Near
Firstly when we create react app it provides us with a basic struct. See the below picture which is taken from the official site.
When we start a project, we may not be able to predict the project will how sophisticated or what we will need. After a lot of time and work, we’ll realize the project is a mess because our code snippets are not in the right places and we’re repeating ourselves uncountable.
There is a way to prevent happening all of the things I mentioned before. The proper folder structure!
Firstly we need a scenario.
Imagine that you got a freelance job. And your employer wants an application where users can criticize each other, comment and vote on posts, sign in up, and after all, can make money from posts with blockchain. The employer says that API is ready to use.
Let’s start to create.
All folders will be in the ‘src’ folder.
PAGES — Obviously, we’ll have pages in this app. So our first folder will be pages. In this folder, we keep our pages. It depends on how you control your styling but I prefer module CSS, so I keep all my pages in separate folders. For example home page’s path looks like ‘./src/pages/Home/Home.jsx’. Add other pages same as this one.
COMPONENTS — In the page, we’ll use components. So we can keep components in this folder. This can contain several folders like;
| — UI Keeps your UI items like buttons, cards, checkboxes, etc.
| — layout In the layout page, we can keep components which not change and use several pages. Wrapping the app.js file with <Layout> </Layout> we settled on the layout with children prop. Look at this link for further information.
ASSETS — We need icons, gifs, fonts, images, and styles in the app. We can keep our files in these.
API — Keeps files related to API.
MODULES — Keeps global modules.
CONTEXT — In the app, we need to keep some data at a global state, if you decide to use context you need this folder.
STORE — If you preferred redux, this folder will be handy. Subfolders can be added. There are multiple patterns for this area. For more information look at this beautiful article
| — ACTIONS
| — REDUCERS
TYPES — Presume that we are selecting typescript for this project, this folder keeps types in it.
UTILS — Every project needs utils. This folder is a tool bag for our project. For example parsers, constants, language files, etc.
| — CONSTANTS
| — HOOKS
| — LANGS
TEST — Keeps test files.
That’s it. You can add other folders to keep the app sustainable. But avoid too much nesting. Read official documentation.
Eventually, the folder struct will look like this.
react-app/
├─ node_modules/
├─ public/
│ ├─ favicon.ico
│ ├─ index.html
│ ├─ robots.txt
├─ src/
│ ├─ api/
│ │ ├─ services/
│ ├─ assets/
│ │ ├─ gifs/
│ │ ├─ images/
│ │ ├─ styles/
│ │ ├─ icons/
│ ├─ components/
│ │ ├─ ui/
│ │ ├─ layout/
│ ├─ modules/
│ ├─ pages/
│ │ ├─ Home/
│ │ ├─ Profile/
│ ├─ context/
│ ├─ store/
│ │ ├─ actions/
│ │ ├─ reducers/
│ ├─ types/
│ ├─ utils/
│ │ ├─ contants/
│ │ ├─ langs/
│ │ ├─ hooks/
│ ├─ __tests__/
├─ .gitignore
├─ package.json
├─ README.md
├─ index.css
├─ index.js
I’m not adding files to this diagram to keep it simple.
Hope it’s helped!
Author: Mahir Uslu
Power BI, Microsoft’un geliştirdiği iş zekası araçlarından bir tanesidir. Elimizdeki veri üzerinde düzenleme, temizleme, analiz etme ve görselleştirme gibi işlemler yapmamızı sağlar. Basit ve sade bir arayüzü vardır. Teknik bilgisi yüksek olmayan kullanıcılarında rahatlıkla kullanabileceği şekilde tasarlanmıştır.
Power BI 3 bileşenden oluşur. Bunlar sırasıyla; Power BI Desktop, Power BI Service ve Power BI Mobile’dir
Desktop : Windows işletim sistemlerinde çalışan, kullanıcının veri kaynaklarına bağlanma, veri seti oluşturma, rapor hazırlama gibi işlemler yapabilmesini sağlayan local bir uygulamadır.
Service : Desktop üzerinde yaptığımız işlemleri web tarayıcılarını kullanarak yapmamızı sağlayan uygulamadır. Desktop’daki bir çok özellik Service’de de kullanılabilir (Rapor oluşturma, kaynaklara bağlanma, kaynakları yönetme vb.), ancak veri seti oluşturma gibi bazı işlemler sadece Desktop uygulamasında yapılabilmektedir. Service uygulamasında sadece Desktop’da üretilmiş hazır veri setlerine bağlanma işlemi yapılabilmektedir.
Mobile : Power BI Servisinde yayımlanan raporları görüntülememize yarayan mobil uygulamadır. Bu uygulamada sadece veri görüntüleme işlemi yapılabilir.
Free, Pro ve Premium olmak üzere 3 farklı lisans tipi bulunmaktadır. Bu lisansların satın alınması ve kullanıcılara atanması portal ofis’te yapılır. (Portal.office.com)
Ücretsiz (Free) Lisans: Herhangi bir ücret ödemenizi gerektirmeyen, kişisel kullanıma daha uygun olan lisans tipidir. Free lisans uygulamaya herhangi bir teknik kısıt getirmez. Fakat bulutta yayınlanmış raporlarınızı başkalarıyla paylaşmak istediğinizde Pro lisansa ihtiyaç duyulmaktadır.
Pro Lisans: Eğer bir rapor setine belli bir kullanıcı grubunun farklı güvenlik seviyelerinde ulaşması gerekiyorsa, kullanıcılar arasında rapor ve dashboard paylaşılması gibi ihtiyaçlar varsa, rapor setinin otomatik olarak kendiliğinden güncellenmesine günde birden fazla ihtiyacınız varsa, rapor setinin verisini çektiği veri kaynakları Pro lisansı gerektiren bir veri kaynağı ise (örneğin SQL Server Analysis Server) “Pro” lisansını kullanmalısınız.
“Pro” lisansının mevcut durumda kullanıcı başına aylık yaklaşık 10$ gibi bir maliyeti var. Pro lisansını “trial” modunda 60 gün ücretsiz olarak deneyebilirsiniz. Free ve Pro lisansı arasındaki farklar zaman zaman değişebiliyor, fakat bu farkların tamamının bulut servisindeki raporların paylaşımı, erişimi ve yenilenmesiyle ilgilidir. Yani, veri modelleme ve raporlama tarafında yapabileceklerimiz free ve pro versiyonda aynıdır. Pro versiyonda Sadece bulut tarafında bazı ek özellikler bulunmaktadır. Free ve Pro versiyon arasındaki farklar için buraya göz atabilirsiniz.
Premium Lisans: Raporlara erişecek kullanıcı sayısı 500 ve üzerindeyse, bulut servisinin yanısıra Power BI’ı on-premise’de de kullanmak gibi bir ihtiyaç varsa Premium lisansını değerlendirebilirsiniz. Premium lisans, bulutta size özel ayrı bir powerbi.com servisi çalıştırmaya benzer, paylaşımlı değil, sadece size ait bir kapasiteyi satın alır ve kullanırsınız. Premium lisans, hem bulutta size ait bir kapasite oluşturur, hem de on-premise’de, yani lokalde kendi “Power BI On-Prem Report Server”’ınızı kurmanıza müsade eder. Eğer buluta çıkmakla ilgili regülasyonlara tabii iseniz Premium lisansını kullanabilirsiniz. Güncel soruların cevapları için buraya bakabilirsiniz.
Author: Deniz Alkan