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”

 

What are the Design and Architecture?

Screen Shot 2018-09-23 at 7.23.12 PM

 

What are the Design and Architecture?

The design is more often seems to when it comes to structures and low-level decisions whereas Architecture is often used in the context of something at the high level where we can see how components are connected with each other. But for starters, there is no different at all.

What is the GOAL of good software design?

The goal of software architecture is to minimize the Human Resources required to build and maintain the required system (By Uncle Bob Martin)

Basic fundamentals measure the design?

The measure of design quality is simply the measure of the effort required to meet the needs of the customer if the effort is low and stays same through the lifetime, System design is good else it’s bad.

The Signature of a system design mess?

  • Developer point of view
    The graph says developers started with nearly 100% of productivity but with each release, their productivity going down

Screen Shot 2018-09-23 at 8.00.44 PM.png

  • Executive point of view?
    Release 1 was delivered with a few hundred thousand payrolls and by the time of 5 release, it’s going to touch $500,000.

Screen Shot 2018-09-23 at 7.55.59 PM.png

What is going wrong?

The moral of the story says everything in one line: “Slow and steady wins the race”. Yes, it all because of overconfidence. Everyone wants to hit the market first or release the app asap with the statement “We can clean it up later” and they can’t go back for cleaning the things up because now we have the new feature, new release so maybe next time, next time and next time.

The only way to go fast is to go well.

To take the software architecture seriously we have to think and need to know what good software architecture is, compare the different architecture with the requirements.

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

Concurrency|Computer Science Core Concepts in Layman’s term

word-image8

image source (google.com)

Let’s say you work as a company secretary and your job is to take the phone calls, manage meetings etc. Every time the phone rings, you have to stop whatever you are doing. A property of a program that allows tasks to run in overlapping time periods.

  1. Parallelism, allows 2 or more tasks to run at the same time (Only if the machine has the multiprocessing capability). You asked your boss and he hired a clerk for taking the call. It looks very simple but concurrency introduces a few problems like the Race condition,
  2. Race Condition, Suppose you have $500 in your bank account, at the same time when you withdraw $200 someone transferred $300 or maybe in simple words same time 2 transaction happened for withdrawing $500.
  3. Mutual Exclusion (Mutex), Solution for the Race condition. Now, whenever some transaction starts it locks the account. if some transaction is going on with your account you cannot withdraw. But next problem is nobody wants to wait every time when there’s is something going on. Semaphore is the modified solution for Mutex.
  4. Semaphore (Improper use of Semaphore will give improper results)
    • Binary Semaphore (Range is from 0 to 1), Idea is to give specific priority to different types of transaction. Withdraw request has a higher priority than bank transfer. So when you withdraw, another transaction for transfer will stop and it will resume once withdraw is completed. (As simple as that, 1 = ongoing transaction, 0 = waiting) Also known as integer semaphore.
    • Counting Semaphore (Range is from -∞ to +∞), Allow more than one process running at the same time. Let’s suppose you’re a key room manager where you have 30 keys if lockers are full users have to wait in the queue. when someone has done they will hand over the key to the first person in the queue.
  5. Deadlock, Another common issue in concurrency modal. Let’s assume user a transferred amount to b and at the same time user b transfer the amount to the user a. both transactions are waiting to complete another one as they can’t access the locked account.

Contact
@buntylm

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.

4 Ways to Solve The Problem | Quick-Notes

Problem-solving requires two types of mental skills, analytical and creative. I know this sounds very high level So let’s talk about the basic fundamentals what generally I try to follow in day to day professional and personal activities.

  1. Listen carefully You need to pay very close attention to any information in the problem description. The optimal solution for a sorted vs unsorted array will be totally different so don’t miss anything.
  2. Brute Force Yes correct, Get the brute force solution as soon as possible, don’t think about the optimal solution. I always catch the first thought that comes to my mind. Don’t think about code, the algorithm just rough idea.
  3. Optimize Now it’s time to work on your Brute Force with some BUD (Bottlenecks, Unnecessary work and last Duplicated work) techniques.
    1. Remove the unused information.
    2. Solve it manually on paper with an example.
    3. Reverse engineer your thought process. HOW DID YOU DO?
    4. Make a Time VS Space trade-off.  CAN YOU REDUCE-IT MORE?
  4. Implement Congratulations now you have an optimal solution on paper. The last goal is to write beautiful, modularize code.

If you are trying to solve the problem in interview KEEP TALKING because your interviewer wants to hear how you’re going to approach the problem and it will make the interview more interactive.

Thanks a lot for reading the quick-notes!

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.