{"@attributes":{"version":"2.0"},"channel":{"title":"Adam Tibi","description":"My blog where I share my software experience and what I encounter in different projects","link":"https:\/\/adamtibi.net\/","pubDate":"Mon, 03 Oct 2022 10:37:19 +0000","lastBuildDate":"Mon, 03 Oct 2022 10:37:19 +0000","generator":"Jekyll v3.9.2","item":[{"title":"Pragmatic Deep Learning Model for Forex Forecasting with Multi-Step Prediction","description":"
\n\"A\n<\/figure>\n\n

This is my post on Towards AI on building an LSTM Deep Learning model that can predict the market:<\/p>\n\n

Pragmatic Deep Learning Model for Forex Forecasting: Using LSTM and TensorFlow on the GBPUSD Time Series for multi-step prediction<\/a><\/p>\n\n\n","pubDate":"Thu, 08 Oct 2020 17:44:00 +0000","link":"https:\/\/adamtibi.net\/10-2020\/pragmatic-deep-learning-model-for-forex-forecasting-multi-step-prediction","guid":"https:\/\/adamtibi.net\/10-2020\/pragmatic-deep-learning-model-for-forex-forecasting-multi-step-prediction","category":["Machine Learning","LSTM","Forex","Deep Learning","Uncategorized"]},{"title":"The day when the software industry makes its mind","description":"

\n\"A\n<\/figure>\n\n

In year 2000 I started writing code professionally while at uni, before that I was writing code as a hobby. I\u00a0was\u00a0fascinated\u00a0by all the best practices I should follow: I shouldn\u2019t use HTML tables for design; they are horrible, I shouldn\u2019t write JavaScript inside my HTML I should do it obtrusively, I should not do database business logic in my code, I would violate the separation layers and I will mix business logic with database logic etc\u2026 Fast forward two decades later, I learned to take everything I hear with a pinch of salt!<\/p>\n\n

The Do it, Don\u2019t, Do it, Don\u2019t Approach<\/h2>\n

They tell you do it; it is good; they tell you not; it isn\u2019t then they change their mind a few years later, then again and again.<\/p>\n\n

Writing server-side code in your HTML<\/h3>\n\n\n\n

When I was a hobbyist, I liked ASP and how you can write some code that is then transformed magically into HTML. You write a bit of HTML tangled with a bit of code and life was cool.<\/p>\n\n

ASP.NET Webforms came along and the major advice, DO NOT<\/strong> write code in your HTML, write it in the code-behind<\/em> otherwise you would be violating the separation of concerns!<\/p>\n\n

ASP.NET MVC came with Razor pages and the advice was \u201cwrite a bit of C# code,\u201d it is ok, sorry for the previous advice, but don\u2019t overdo it and be a good boy.<\/p>\n\n

Single Page Applications (SPA), DO NOT<\/strong> write any code in your HTML, better not even dealing with that, let the client deal with it, what were you thinking?!<\/p>\n\n

Mixing database queries with business logic<\/h3>\n\n

Writing database logic inside your code would violate the separation of concerns. One of the reason of failures of applications such as MS FoxPro and MS Access was this. Writing stored procedures for your business logic are even worse (please don\u2019t shoot the messenger) because you are scattering your business logic on multiple layers (and million other reasons).<\/p>\n\n

Later on, the Object Relational Frameworks (ORMs) such as Hibernate (Java), Active Record (Ruby on Rails) and Entity Framework (.NET) came along! Now writing database logic inside your code is fine again! But you don\u2019t call it \u201cdatabase operations\u201d anymore, otherwise you become uncool.<\/p>\n\n

Designing with tables<\/h3>\n\n

Prior to 2003, if you were to write a web page, you probably would use HTML tables to control your layout. Then the CSS started becoming more supported and the advice changed; DO NOT<\/strong> use tables for layout and you could find blogs of over 10 reasons of why you shouldn\u2019t do it.<\/p>\n\n

Bootstrap and later on CSS Flexbox came along, you know what, they have Grid<\/strong>, not Table<\/strong>, Grids are fine, even though the used CSS classes are called row<\/code> and col<\/code> and now grids are fine!<\/p>\n\n

Unobtrusive<\/h3>\n\n

When Netscape introduced JavaScript, developers used to write JavaScript events mixed with HTML, the button will have an onclick<\/code> and then the JavaScript code. Then jQuery came along with the unobtrusive<\/strong> concept (I like this keyword and I learned to pronounce it quickly without stuttering) and now dare you say to a front-end developer to write JS code inside HTML.<\/p>\n\n

Years went by, jQuery became uncool and now the Single Page Application frameworks (React, Angular, Vue, etc\u2026) came to the rescue. And guess what, you are better using JavaScript or framework-specific keywords inside HTML and now it is ok, think (click)=\"onClickMe()\"<\/code> in Angular, we were kidding when we\u2019ve said obtrusive JS is bad!<\/p>\n\n

You should not be using Flash or Silverlight, or else!<\/h3>\n\n

Flash and Silverlight suddenly became bad practice, as they require a plugin to work in the browser and the advice became not to use them because you should be using HTML5. Ok, I got it, plugins are bad, I would not encourage using them. Years later Web Assembly<\/a> came along.<\/p>\n\n

Did you know, you are allowed to write code that executes as a web assembly, all the stuff we said about plugins are no longer relevant. Writing non-JS code in the browser is fine again, such a wonderful world :)<\/p>\n\n

Conclusion<\/h3>\n\n

The irony is that I agree with the logic change and why things went in the other direction, it all make sense to me. Today, what I\u2019ve learned is to always have an open mind for change where it makes sense and to have more flexible opinion in my technical discussions, as every thing will change later on.<\/p>\n\n","pubDate":"Mon, 29 Jul 2019 07:44:00 +0000","link":"https:\/\/adamtibi.net\/07-2019\/the-day-when-the-software-industry-makes-its-mind","guid":"https:\/\/adamtibi.net\/07-2019\/the-day-when-the-software-industry-makes-its-mind","category":["CodeProject","Software","Best Practices","Uncategorized"]},{"title":"Ten software keywords that make you look smarter","description":"

\n\"A\n<\/figure>\n\n

They say the coat doesn\u2019t make the man, I say the right quote can make a developer punch above the waistline. In this post, I selected a group of my favourite keywords which make me smile and think \u201cnerd\u201d every time I hear one.
\n<\/p>\n\n

1 \u2013 The God Function<\/h2>\n\n

This is the all-in-one function (method). It is one function that does everything, is it like 100 lines or more. Obviously, writing a God Function contradicts with clean and readable code principles and usually the people guilty of using it are beginners and pros coming from other domains (like mathematicians).<\/p>\n\n

This term is usually used in a sarcastic way to mock a function that is long and needs refactoring.<\/p>\n\n

2 \u2013 Vertical Concerns<\/h2>\n\n

It is a concern not directly related to the piece of code that you write. So, when you are writing some code to save a user info in the database, logging the event and notifying other systems that a record has been added are mostly vertical concerns.<\/p>\n\n

Vertical concerns are usually dealt with in C# with attributes, Membership Provider attributes are a good example.<\/p>\n\n

3 \u2013 Cross-Cutting Concerns<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

Cross-cutting concerns are aspects of a program that affect other concerns. These concerns often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and can result in either scattering (code duplication), tangling (significant dependencies between systems), or both.<\/p>\n\n

For instance, if writing an application for handling medical records, the indexing of such records is a core concern, while logging a history of changes to the record database or user database, or an authentication system, would be cross-cutting concerns since they touch more parts of the program.<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/Cross-cutting_concern<\/a><\/p>\n\n

4 \u2013 HATEOAS<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).<\/p>\n\n

The HATEOAS constraint decouples client and server in a way that allows the server functionality to evolve independently.<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/HATEOAS<\/a><\/p>\n\n

I first heard this term long time ago (2009?) from Jim Webber<\/a> when I was attending an event on REST.<\/p>\n\n

5 \u2013 Ubiquitous Language<\/h2>\n\n

Quoting from Martin Fowler:<\/p>\n\n

\n

Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software \u2013 hence the need for it to be rigorous, since software doesn\u2019t cope well with ambiguity.<\/p>\n<\/blockquote>\n\n

https:\/\/martinfowler.com\/bliki\/UbiquitousLanguage.html<\/a><\/p>\n\n

6 \u2013 Fluent Interface<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

A fluent interface (as first coined by Eric Evans and Martin Fowler) is an implementation of an object oriented API that aims to provide for more readable code.<\/p>\n\n

A fluent interface is normally implemented by using method cascading (concretely method chaining) to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining). Generally, the context is defined through the return value of a called method self-referential, where the new context is equivalent to the last context terminated through the return of a void context.<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/Fluent_interface<\/a><\/p>\n\n

A theoretical example of a fluent interface usage would be something like:
\nmember.Name(\"Adam\").Country(\"England\").City(\"London\");<\/code><\/p>\n\n

7 \u2013 Optimistic Concurrency Control<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

Optimistic concurrency control (OCC) is a concurrency control method applied to transactional systems such as relational database management systems and software transactional memory. OCC assumes that multiple transactions can frequently complete without interfering with each other. While running, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the data it has read. If the check reveals conflicting modifications, the committing transaction rolls back and can be restarted. Optimistic concurrency control was first proposed by H.T. Kung.<\/p>\n\n

OCC is generally used in environments with low data contention. When conflicts are rare, transactions can complete without the expense of managing locks and without having transactions wait for other transactions\u2019 locks to clear, leading to higher throughput than other concurrency control methods. However, if contention for data resources is frequent, the cost of repeatedly restarting transactions hurts performance significantly; it is commonly thought that other concurrency control methods have better performance under these conditions. However, locking-based (\u201cpessimistic\u201d) methods also can deliver poor performance because locking can drastically limit effective concurrency even when deadlocks are avoided.<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/Optimistic_concurrency_control<\/a><\/p>\n\n

8 \u2013 Cyclomatic Complexity<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate the complexity of a program. It is a quantitative measure of the complexity of programming instructions. It directly measures the number of linearly independent paths through a program\u2019s source code.<\/p>\n\n

Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.<\/p>\n\n

One testing strategy, called basis path testing by McCabe who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the cyclomatic complexity of the program.<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/Cyclomatic_complexity<\/a><\/p>\n\n

I was first introduced to this term by ReSharper when a legacy code showed as high cyclomatic complexity.<\/p>\n\n

9 \u2013 Responsive Web Design<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

Responsive web design (RWD) is a web design approach aimed at crafting sites to provide an optimal viewing experience\u2014easy reading and navigation with a minimum of resizing, panning, and scrolling\u2014across a wide range of devices (from mobile phones to desktop computer monitors).<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/Responsive_web_design<\/a><\/p>\n\n

10 \u2013 Duck Typing<\/h2>\n\n

Quoting from Wikipedia:<\/p>\n\n

\n

With object-oriented programming languages, duck typing is a style of typing in which an object\u2019s methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of an explicit interface. The name of the concept refers to the duck test, attributed to James Whitcomb Riley (see history below), which may be phrased as follows:<\/p>\n\n

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.<\/strong><\/p>\n\n

In duck typing, a programmer is only concerned with ensuring that objects behave as demanded of them in a given context, rather than ensuring that they are of a specific type. For example, in a non-duck-typed language, one would create a function that requires that the object passed into it be of type Duck, in order to ensure that that function can then use the object\u2019s walk and quack methods. In a duck-typed language, the function would take an object of any type and simply call its walk and quack methods, producing a run-time error if they are not defined. Instead of specifying types formally, duck typing practices rely on documentation, clear code, and testing to ensure correct use.<\/p>\n<\/blockquote>\n\n

https:\/\/en.wikipedia.org\/wiki\/Duck_typing
<\/a><\/p>\n\n

Conclusion<\/h2>\n\n

Joke aside, if I am interviewing someone and he\/she is using some key phrases, where relevant, this would be a great plus which proves they know what they are talking about.<\/p>\n\n

We advise using these keywords in an interview with caution\u2026<\/p>\n","pubDate":"Mon, 08 Sep 2014 19:44:00 +0000","link":"https:\/\/adamtibi.net\/09-2014\/ten-software-keywords-that-make-you-look-smarter","guid":"https:\/\/adamtibi.net\/09-2014\/ten-software-keywords-that-make-you-look-smarter","category":["C#","CodeProject","Interview","Uncategorized"]},{"title":"Implementing a CQRS architecture with MVC and Document DB","description":"

\n\"MVC\n<\/figure>\n\n

This is a sample implementation of ASP.NET MVC4, MongoDB and Ninject to act as a starting template if you are going to use these technologies in your project with a CQRS pattern.<\/p>\n\n

Audience<\/h2>\n\n

If most of these terms look unfamiliar then this post is probably not for you: CQRS, Repository, Aggregate (of DDD), NuGet, Unit Testing, Dependency Injection, Document DB. Due to the scope of this post, I won\u2019t be able to go in details in any of these topics as this is a direct implementation.<\/p>\n\n

Greg Young did a few paragraphs intro on CQRS here: CQRS, Task Based UIs, Event Sourcing agh<\/a>, if you want a simple intro I recommend at least reading the first half of Greg\u2019s post (before the Event Sourcing).<\/p>\n\n

Scope and Definition<\/h2>\n\n

In this post, I mean the plain-CQRS pattern and not the whole patterns that are associated with CQRS. Plain CQRS opens the door for other patterns such as Event Sourcing and ES is usually associated with CQRS. This is the plain CQRS with no other associated pattern.<\/p>\n\n\n\n

Choice of Technology<\/h2>\n\n

I chose MongoDB due to its open licence policy and simplicity, Ninject due to its licence, simplicity and Ninject.Extensions.Conventions<\/code> extension that makes my code DRYer.<\/p>\n\n

I could have chosen SQL Server, but for simplicity reasons and to get the idea across, Document DBs are easier to work with. You could also tweak this sample implementation to work on an RDBMS as long as you get the repository right.<\/p>\n\n

This is a sample implementation of ASP.NET MVC4, MongoDB and Ninject to act as a starting template, in case you are going to use these technologies in your project with a CQRS pattern.<\/p>\n\n

Task Application<\/h2>\n\n
\n\"Task \n<\/figure>\n\n

This is meant to be a trivial application, so that the focus is shifted from the features to the MVC with CQRS pattern. The application:<\/p>\n\n