Hello World

    Here it is, finally! I've been meaning to blog about my thoughts on programming for a long time, but somehow I never could find the time to do it.

    I've been a programmer working from 9 to 5 for the most of my career. A little over a year ago I decided to become an independent software developer. I came up with what sounded like a great plan: create an app or two, put them in the app store, build up the user base, and then the money will start flowing in. I calculated how many users I need to make a living out of it and I made a list with ideas about applications that I could build. I did my research and I ordered the list by simplicity of the apps and then by the total number of installs of similar apps in the app store. I rolled up my sleeves and went off to build my career as an independent software developer.

    The last year was a wild ride. In total I created three apps in three different languages and my own MVVM library, I brushed up my math skills, solved hundreds of academic programming problems, watched a ton of lectures on programming, and I finally read some of the books on programming that have been sitting on my bookshelf for a long time. And now I am making the next step in my journey, I am starting my own company called Viasoft.

    I am proud to say that Viasoft is finally open for business. We can build custom software tailored to your exact needs or we can consult you and help you build it yourself. Give us a call and tell us how we can help you. In the meantime, stay tuned for more blog posts. Cheers!

Popular posts from this blog

The Database is a Detail

    I've seen many applications where the database is in the center. In these applications the database is the most important part and everything else is just a shell around it. In most of the applications that I've seen, they use an ORM, and in some they use plain SQL. All of them had business objects without any behavior. All of the behavior, all of the business rules were in the database. I want you to think about that!      What's an "object" in the sense of object-oriented programming? What characterizes an "object " ? The first sentence in Wikipedia about object-oriented programming states: Object-oriented programming ( OOP ) is a programming paradigm based on the concept of " objects ", which can contain data and code : data in the form of fields (often known as attributes or properties ), and code, in the form of procedures (often known as methods ).      An object can contain data and code. In other words an object has data and
Read more

SOLID Series: The Single Responsibility Principle

     I am starting a series about the SOLID Principles of Object-Oriented Design. These are five principles that you should keep in mind when designing an object-oriented program. They are coined by different authors in different moments in time. You can say that they are hard learned lessons from the past.     Today I am going to write about the first of the five principles - The Single Responsibility Principle . It was coined by Robert C. Martin, a.k.a. Uncle Bob. The narrative usually goes along the lines of: "The SRP means that a class should do just one thing". I want you to think very carefully about this. I want you to think about it because it's a lie!     Imagine what a program made of classes which do just one thing would look like! I've actually seen such a program. The claim was that it conforms to the SRP, but nothing could be further from the truth! I'll spare you the details and I'll show you only the code that illustrates the point. I
Read more

The Technical Debt Metaphor

    I love metaphors. Metaphors help me better understand an abstract idea. Software development is filled with metaphors. One of the metaphors widely used in software development, albeit often misunderstood, is technical debt. Technical debt is a term coined by Ward Cunningham , you can hear what he has to say about it here . Technical debt is a metaphor that refers to a very particular problem. Making a decision when you have limited understanding of the problem domain, or making a decision that will speed up the development now, but might slow you down in future.      Imagine I have a confusing module in my code. I wrote it early on in the development, when I had a limited understanding of the problem domain. It's been months and the module has been working fine without any sign of trouble. Now I have to add a new feature to it. I realize that while the internal quality of the module is good, it represents the limited understanding that I had. Adding the new feature will take
Read more