The table of two values, Behaviour and Structure!

The table of two values, Behaviour and Structure!

Is it more important for the software system to work or is it more important to be easy to change? If you ask the business managers they will say work is more important, some developers also go along with this attitude but that’s the wrong attitude.

Why the wrong attitude?

  1. If you give me a program that works perfectly but impossible to change, it means it won’t work when the requirements change.
  2. If you give me a program that does not work but easy to change, it means I can make the change to make it work.

If you’re a programmer with the attitude (1.) then one day your system will reach to the point where the change will be impractical (cost of change will be unaffordably high).

Eisenhower Matrix

Eisenhower said, I have two kinds of problems, the urgent and the important, where the urgent are not important and the important is never urgent.

when it comes to software, The first value of software is behavior, is urgent but not always important. The second value is architecture, is important but never urgent. Of course, some things are not urgent and not important.

  1. Urgent and important
  2. Not urgent and important
  3. Urgent and not important
  4. Not urgent and not important.

Screen Shot 2018-09-24 at 9.51.23 PM

Mistakes that business managers and developer make is to elevate items in position 3 to 1. It means they always fail to separate those features that are urgent but not important from those features that are really urgent and important and this failure leads to ignoring the important architecture of the system in favor of the unimportant features of the system.

So if you are a software developer, you are hired to maintain the quality and structure of the system and only you know the importance of the architecture.

Thanks for reading it, if you want to read in more detail, buy “Clean Architecture by Robert C. Martin”

 

Swift Keynotes: classes & structs

  • Structs are the value type.

Screen Shot 2018-07-16 at 4.52.45 PM.png

  • Classes are the reference type.

Screen Shot 2018-07-16 at 4.51.19 PM.png

  • Properties of a constant instance of the struct are immutable because struct’s instance own the whole object and by declaring it as a constant means the whole object itself will be immutable.

Screen Shot 2018-07-16 at 4.59.08 PM.png

  • Properties of a constant instance of the class are mutable as class’s instance owns the object’s reference thus by declaring it as a constant only means that the further reference assignment can’t be done.

Screen Shot 2018-07-16 at 5.01.29 PM.png

  • Structs are blessed with default member-wise initializer but classes are not.

Screen Shot 2018-07-16 at 4.02.52 PM.png

  • Structs are preferable when they are small and copyable.
  • With Structs, there is much less need to worry about memory leaks or multiple threads racing to access/modify a single instance of a variable.
  • Since struct instances are allocated on the stack, and class instances are allocated on the heap, structs can sometimes be drastically faster (but it still depends on how many values you’re storing and the size/structure.)
  • In a multi-threaded environment, for instance, with a database connection that’s opened in a different thread, structs are safer. They can be copied from one thread to another thread, without running the risk of a race condition or deadlock. Classes do not have this inherent safety unless they’re deliberately made thread-safe.

Thanks a lot for reading it.

iOS Wireless Install, Debug Builds using WiFi | Quick Notes

Yes, correct you heard it right. It was the most awaited feature because nobody wants to spend a lot on Apple connectors, haha. But unfortunately, I don’t see people are utilizing this features. So here we go with one to kick start.

Prerequisites:

  1. iOS device with later or iOS 11 OS version.
  2. MacBook with macOS 10.12.4 or later.
  3. Xcode IDE with 9 or later
  4. Developer Macbook and iOS device should be on same WiFi network.

I hope after reading prerequisites you are clear about what is gonna happen. Let’s move on further steps.

Step: 1 Here you need your connector cable for first and yes last time. Connect your iOS device and open Xcode.

Step 2: Switch to,Window,Devices and Simulators options, below is the screen for reference.

Screen Shot 2018-03-28 at 10.44.58 AM.png

Step 3: Just enable the optionConnect via network.

Step 4: Sometimes it will ask you to provide your iOS device IP to enter but in my case, it didn’t ask.

Thanks for reading!

Creating and Distributing iOS Frameworks | Swift | Tips & Tricks

Why do we need to create frameworks? because it has three major purposes mentioned below and also you can share your code with your team, other developer or iOS community.

  • Code encapsulation
  • Code modularity
  • Code reuse

Let’s create the iOS framework.

Screen Shot 2018-02-05 at 8.24.50 PM

Now just give some meta-data about your framework like name, organization, identifier etc (I hope you’re already aware of it).

Screen Shot 2018-02-05 at 8.26.54 PM.png

We’re good to go till now. Just add the files that you want to keep within your framework.

add

Build the framework project to make sure that you get build succeeded with no build warnings or errors.

Things that you need to take care.

  • Make sure to check Copy items if needed, so that the files actually copy into the new project instead of just adding a reference. Frameworks need their own code, not references, to be independent.
  • Double-check that each of the files has Target Membership in ThreeRingControl to make sure they appear in the final framework. You can see this in the File Inspector for each file.
  • Double-check the access modifiers, while creating framework access modifiers plays very important roles.
  • if you’re creating Swift framework make sure you’re extending classes from NSObject otherwise it won’t reflect once you will import the framework.

Thanks for reading.

STUPID principles | Quick Notes

Recent blog: SOLID vs STUPID

STUPID principles and yes this may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton

Well known design pattern, but mostly understood one as well. Like me, people are also fighting with Singleton syndrome. In that case, whenever we create a class we create it Singleton but why? That is definability not cool. Singleton also considered anti-patterns. We should think and avoid if possible because the program using Singleton are hard to test because of global state, with the global state they hide their dependencies.

Tight Coupling

Avoiding static things is important to avoid tight coupling. If it’s there then making a change in one module requires to changes another module too. Now it’s really difficult to reuse and difficult to test.

Untestability

Testing is not hard, what you think? We don’t write test case may be because we don’t have the time or the code we are writing is bad because of tight coupling?

Premature Optimization

One of my favorite quote from Donald Knuth, premature is the root of all evil. There are only cost and no benefits. Actually optimised code is much complex as compared to just writing a loop.

Indescriptive Naming

That’s what I like most and I try to follow as much as possible. Name of your class, variables or methods should be clear because at the end of the day human is only going to read because programming languages are for human not for computers, computers can understand 0 or 1 very well.

Duplication

That’s bad. Writing same code again and again so don’t repeat yourself, keep it simple and strong. Write Code only once.

Thank you for reading the quick introduction of STUPID principles, next will be SOLID principles.

SOLID principle with Swift | STUPID

SOLID principle is an acronym created by Robert C Martin also unknown as Uncle Bob. It represents five principles for OOPS.

Single responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

Now the first thought that came to my mind is Why do we need this? Here is the answer, using these principles we can solve the problems of a bad architecture.

Fragility where A small change may break complete module it’s really very difficult to find this if you don’t have good test cases.

Immobility where A component is very hard to reuse in another project or we can say multiple places in the same project because of too many dependencies.

Rigidity where Single change requires lots of developer efforts because it affects several parts of the project.

Here I want to add principles will not turn a bad programmer into a good programmer you need a better judgment there. Principles have to apply with judgment and you must be smart enough to understand when to apply what.

I have also written one blog where they have mentioned one more acronym like SOLID and it’s STUPID. This may hurt your feeling but yes if you are following this you are writing stupid code.

Singleton
Tight Coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

Thank you for reading the quick introduction, In next blogs, I will try to define all principles with Swift Code.

Signs of wrong architecture? | Quick Notes

Recently I have got one iOS Application codebase to review and it always gives a thought, where to start?

Here are the 3 important first steps for me that I always do.

find . -type f -exec wc -l {} + | sort -n

Execute the terminal command in your project location, it will give you count of number of lines, like mentioned below

3000 ./ViewControllers/DashboardVC.swift
5655 ./AppDelegate.swift

where 3000/5655 is the lines of code.

Second, I track are we using Appdelete directly?

grep -rnw . -e "UIApplication.shared"

Last, but not the least. Swift/Objective-C dependency visualizer. It creates object dependency graphs and gives you the clear picture.

Screen Shot 2017-11-22 at 5.33.12 PM

Thanks for reading. I hope it was quick and informative for you.