SalaryTDS

salarytds

The Art of Naming Conventions in JavaScript Development

Golang: a RESTful API Using Temporal Table With MariaDB

During a time of crisis, in 2020 being unemployed, looking for jobs, and going to interviews almost every day, I found myself devastated after a four-round interview. I sat down after reading the rejection email and was thinking about what was the one thing that I remember from that interview. Yes, it was the part where I believe I mess up. It wasn't technicality, it wasn't that I didn't know the answers, it simply was that they came up with a question I was not expecting. What is the best line of code you've ever written? This question literally froze me, got me brainstorming and thinking about all the lines of code I've written. I misunderstood this question in terms of complexity, I thought "best line" meant "tough or hard" which got me thinking about sophisticated lines of code. Something like: staff.filter( worker.isSenior).map( p.salary + p.salaryTax).reduce( acc + curr, ) => worker => p ( ) => acc, curr 0 Doing multiple functionalities in one line was the main thing that came to my head. But the question was not about functionality, or simplicity, or efficiency, or how hard it is to actually write that line of code. After doing all the thinking and realizing that this question was the reason why I did not get hired, I realized this question was . SYMBOLIC And I started to think about a line of code that really means something for me, that changed the way I code and the way I look at problems. I went to square 1 and came out with the line of code that as many other developers, got me started in the industry. The line of code that made me pursue a career in computer science and that motivated me to learn more and to explore other areas and programming languages. This was the first program I ever made. A line of code that I will never forget regardless of what my favorite language (JS) is. This symbolized how much I wanted to become a developer. "The best line of code I've ever written with no doubt is: cout<< <<endl; "Hello World " it symbolized how my passion for programming came to life, how I decided to pursue a career in the computer science field, and it was the beginning of who I am today. This line of code will always hold a special place in me, and even though I do not code much in C++, it was the programming language that I started my career with. For other developers, it might be Java or Ruby or Javascript or others, but for me it was C++." This was the type of answer that I should have said and elaborate on it. For those of you who are going to interviews to become a developer, my only advice will be to be yourself at all points and speak your mind. Just because they came with a question you didn't study, that does not mean it is over, just answer the question as any other question, straight from your heart.

What is the best line of code you've ever written?

I went to an OOP workshop by Sandi Metz several years ago. She made a comment that at one of her previous jobs, they didn't use statements. if What? I had no idea how that was even possible. I recently got interested in this idea again while refreshing my knowledge of design patterns. That's when I began to come across things like the and " " anti-IF campaign Death to the IF statement. At this point, I didn't know if coding without conditionals was really a idea, but I saw that at least there were other presumably intelligent people who've thought about it and had strong opinions. good Assuming for a second that you can code without statements, why should you? if The guiding idea behind coding without statements is the Open/Closed Principle (the "O" from SOLID). if From Wikipedia: In , the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be extended without modifying its . object-oriented programming [1] source code The last line is the important one. To follow the Open/Closed principle, you've got to be able to add new functionality to an entity (or ) without changing its source code. class When you don't follow this principle, you end up with conditional spaghetti monsters. Why? Because as requirements change or get added, you can always just tack on an extra . This can lead to wildly complex code that's next to impossible to change. if So how can you do it? Let's look at a quick example. First, keep in mind that this is a trivial example, and it might not actually be a good candidate in a real work environment for this kind of refactoring. (It's also just using instead of doing anything real.) puts But, to keep this somewhat short, we need a simple example. So here goes. Here's a bit of code about paying an employee in Ruby. Essentially it's simulating sending out monthly payments based on either your salary or the number of hours you've worked. It's got a conditional in the method that we want to eliminate. #send_payment , @name = name
    @payment_details = payment_details !payment_details[ ]. ?
      hourly_rate = payment_details[ ].to_f
      number_of_hours = payment_details[ ]
      amount = (hourly_rate * number_of_hours).round( )
      puts amount = (payment_details[ ].to_f / ).round( )
      puts jennifer = Employee.new( , { })
jennifer.send_payment

max = Employee.new( , { , })
max.send_payment class Employee attr_reader :name :payment_details def initialize (name, payment_details = {}) end def send_payment if :hourly_rate nil :hourly_rate :number_of_hours 2 "Sending $ to " #{amount} #{name} else :salary 12 2 "Sending $ to " #{amount} #{name} end end end "Jennifer Smith" salary: 135000 "Max Baxter" hourly_rate: 92.50 number_of_hours: 122 If we want to pull the statement out of the method, we can refactor this using the . if Strategy Pattern @payment_details = payment_details (payment_details[ ].to_f / ).round( ) @payment_details = payment_details hourly_rate = payment_details[ ].to_f
    number_of_hours = payment_details[ ]
    amount = (hourly_rate * number_of_hours).round( ) , @name = name
    @payment_details = payment_details strategy = strategy_class.new(payment_details)
    amount = strategy.amount
    puts jennifer = Employee.new( , { })
jennifer.send_payment(SalaryStrategy)

max = Employee.new( , { , })
max.send_payment(HourlyStrategy) class SalaryStrategy attr_reader :payment_details def initialize (payment_details = {}) end def amount :salary 12 2 end end class HourlyStrategy attr_reader :payment_details def initialize (payment_details = {}) end def amount :hourly_rate :number_of_hours 2 end end class Employee attr_reader :name :payment_details def initialize (name, payment_details = {}) end def send_payment (strategy_class) "Sending $ to " #{amount} #{name} end end "Jennifer Smith" salary: 135000 "Max Baxter" hourly_rate: 92.50 number_of_hours: 122 As you can see, we're injecting the strategy into the method to send payment, and now our if statement is gone. Well, sort of... Deep down, we all know that up in our controller (or wherever) we'd have something like this: ... @employee.hourly?
      @employee.send_payment(HourlyStrategy) @employee.send_payment(SalaryStrategy) ... < ApplicationController class PaymentsController def run if else end end end We could refactor that to make it look less duplicated, but in the end, there would still be an if statement buried in there. So how can we truly get rid of that statement? if In my example, there is some execution code at the bottom. It creates a couple of employees and them pays them. Let's update that to contain a type attribute as well. payment_details = { , }
jennifer = Employee.new( , payment_details)
jennifer.send_payment(SalaryStrategy)

payment_details = { , , }
max = Employee.new( , payment_details)
max.send_payment(HourlyStrategy) salary: 135000 type: "salary" "Jennifer Smith" hourly_rate: 92.50 number_of_hours: 122 type: "hourly" "Max Baxter" Since we're using Ruby, now we can do something like this: Module.const_get( ) class StrategyFactory . def self for (payment_details) " Strategy" #{payment_details[ ].capitalize} :type end end Now, we can refactor our execution code to just use the factory. payment_details = { , }
jennifer = Employee.new( , payment_details)
jennifer.send_payment(StrategyFactory. (payment_details))

payment_details = { , , }
max = Employee.new( , payment_details)
max.send_payment(StrategyFactory. (payment_details)) salary: 135000 type: "salary" "Jennifer Smith" for hourly_rate: 92.50 number_of_hours: 122 type: "hourly" "Max Baxter" for If we assume that the attribute is coming from the database (or similar), We just need to tag people with the right in the database and then add a new strategy class. type we can now add new payment strategies without ever modifying the Employee class. type So, it follows the Open/Closed principle. Nothing in engineering is free though, so what are the tradeoffs? First of all, for simple situations, the new version is much more challenging to get your head around. There are several classes that are likely all in different files. Before we made the change, we could read one simple paragraph and understand what was going on. Now we need to look at a system of small objects. Personally, I prefer the small objects, but in reality, I'd leave the code alone until a new requirement was added. Conclusion I'm probably going to continue using conditionals in my code, but exercises like this are great to do so that you have fresh ideas while you're doing your real work. It's also important to keep things like the Open/Closed principle in the back of your mind so you know when you are violating it and can decide when it's worth it make updates in order to adhere to it.

Can You Really Code Without IF Statements?

A high salary can make you feel like you’re on cloud nine. For cloud engineers, jobs with these sky-high paychecks are in no short supply. In fact, the number of cloud engineer jobs on Indeed.com increased by over 55% between May 2017 and May 2019. And candidate interest is also skyrocketing: The number of people searching for cloud engineer jobs increased by over 52% in that same time period. Since salary levels depend so heavily on the law of supply and demand, certain cities pay a lot more for cloud engineers than others. But where can you find the best cloud engineer salary? To answer this question, we decided to dig deeper and uncover the top 10 top-paying cities in the United States for cloud engineers—so you know exactly where your cloud skills can earn you the big bucks. How much do cloud engineers make? More than half of enterprise companies spend $1.2M annually on public cloud (with 13% spending over $12M per year). This means cloud computing is a top priority—and companies are willing to pay top dollar for cloud engineering talent to design, maintain and operate it. In fact, according to Indeed’s salary estimate, based on 2,505 employees, users, and past and present job advertisements, the average cloud engineer salary in the United States is . $118,994 per year But there are a few cities where cloud engineers can earn an even more lucrative salary (often well above this national average). Don’t worry, we’ve adjusted our figures for cost of living so you’ll get a more accurate representation of each salary’s true value and see just how far your paycheck will go across the map. Some high-paying cities included in this list may surprise you. Philadelphia, PA (#6), Kansas City, MO-KS (#8) and Phoenix, AZ (#10) aren’t exactly places you expect to have a strong tech presence. However, it makes sense that employers in these under-the-radar tech hubs are willing to pay a pretty penny to entice cloud engineers to move (or stay) there. It’s also interesting to note that neither San Jose (Silicon Valley) nor New York, two of America’s largest tech hubs, make the top 10 highest-paying cities for cloud engineers. This means that well-known, established tech centers don’t necessarily pay cloud engineers the best, even after salaries are adjusted for cost of living. And while the job market is more favorable for cloud engineers in smaller cities, a higher supply of tech workers in these more traditional tech epicenters puts employers in the driver’s seat. With more cloud talent comes more competition, and cloud engineers in larger cities might have to accept lower salary offers to prevent employers from moving on to the next qualified applicant. Top five cities with sky-high cloud engineer salaries Now that we’ve uncovered the top 10 highest-paid cities for cloud engineers, let’s take a closer look at the top five to discover why cloud engineers earn healthier paychecks in certain locations. 1. Charlotte, NC Topping our list of the highest-paid cities for cloud engineers is Charlotte, NC, where the COL-adjusted average salary for cloud engineers is 8% above the national average at $128,733.75 per year. Why do cloud engineers in Charlotte make so much? As we mentioned before, demand outweighs supply. And this demand is only set to increase in the coming years. For example, colocation provider Flexential in the Queen City by 20,000 sq ft., bringing the company’s total data center footprint in Charlotte to 129,000 sq ft. Since cloud technologies run in data centers like these, this expansion—and others like it—will likely contribute to a further boost in employer interest (and salaries) for cloud engineers in the area. recently expanded its flagship data center 2. San Francisco, CA San Francisco is notorious for being one of America’s most expensive cities. And while it’s true that the cost of living has outpaced salary growth for many tech roles in the Bay Area, cloud engineers here make $125,429.62, which surpasses the national average salary for cloud engineers by 5%—even after adjusting for the cost of living. Like all the cities on our list, demand is one of the main drivers of high cloud engineer salaries. In fact, San Francisco has the second in the US. And while there may be more competition for cloud engineer jobs here, the city’s mix of venture capital, hot demand and concentration of high-profile tech companies—like Reddit, Pinterest and Airbnb—make it an extremely well-paid area for those with cloud skills. This is especially true since big-name companies are often willing to pay higher-than-average salaries to attract the top cloud engineers in the nation. most cloud engineer job openings 3. Atlanta, GA Coming in at third is Atlanta, GA. Not only are cloud engineers among the top 20 most in-demand tech roles in Atlanta, but the city also hosts a huge data center presence. Businesses here can rent space for computing hardware at one of the city’s (the most data centers out of our top five highest-paying cities). In fact, the QTS Atlanta-Metro Data Center is one of the biggest data centers in the world, sprawling across nearly one million square feet of space. 39 colocation data centers This ecosystem of exploding cloud engineer demand and expanding opportunities in cloud technologies has created an environment where the average cloud engineer can expect to earn a COL-adjusted salary of $119,974. 4. Austin, TX In fourth place is Austin, where the average annual pay for a cloud engineer is $118,060.13. In recent years, the Texas capital famous for its music, eclecticism and laid-back culture has emerged as a bustling high-tech hub. Tech titans like Facebook and Apple have established large outposts in the city, and cloud startups like Spanning Cloud Apps and Apposphere are cropping up to take advantage of one of the nation’s more affordable tech communities. Since there’s so much tech activity in this area, a lot of companies are searching for cloud engineering talent, which has driven up salaries in the city. In fact, cloud engineers are one of the top 20 most sought-after tech roles in Austin, according to Indeed data. 5. Denver, CO The Denver metro area is home to . That’s nearly as many tech companies as San Francisco, which is home to 10,869. The Mile-High City also boasts the second most data centers on this list after Atlanta, with scattered across the metro area. This concentration of tech companies and data center facilities translates to huge demand for cloud engineers—and high salaries to match it. In fact, cloud engineers in Denver earn an average of $115,756.48 per year. 10,151 tech companies 38 colocation data centers What’s more, demand for cloud skills is growing fast. Denver-based cloud services company Faction, for example, closed an in 2018, and accumulated another $14 million in funding in 2019 to expand its cloud services. The company also added 50 new employees to its Denver office within six months, further highlighting the city’s accelerated pace of cloud adoption. $18 million round of Series B funding A sunny outlook for high cloud engineering salaries As companies large and small turn to cloud solutions as a default, demand for cloud engineers will continue to soar. And the cloud supply-demand mismatch gives you the freedom to take your talents to a city where your paycheck goes further, whether that’s in a relatively unknown tech hotspot like Kansas City, Missouri or a leading tech hub like San Francisco. *Methodology: Indeed analyzed the percentage change in the share of job postings with “cloud engineer” in the job title and the share of job searches per million for “cloud engineer” over a two-year period from May 2017 to May 2019. Our analysis for the highest paying cities was calculated based on the average salaries listed on “cloud engineer” job postings on Indeed.com in the US over a two-year period from May 2017 to May 2019. The average national cloud engineer salary was taken from , which was based on 2,505 employees, users, and past and present job advertisements in the three-year period from June 2016 to June 2019. Indeed Salaries

The Ten Top Cities for Highest Cloud Engineering Salaries

and what hides behind it This is a second post (check the Single-responsibility principle ) on principles and what common foundation they all have. here SOLID Bertrand Meyer, 1988 Here is what Bertrand Meyers writes in his book “ ” where this principle originates from: Object Oriented Software Construction A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients. So he proposed using an . Not good at all. implementation inheritance Robert Martin, 1996 Poor Robert Martin is often blamed for what actually Bertrand Meyer proposed. No wonder, look what he wrote in his paper “ ”: The Open-Closed Principle 1. They [Modules, as well as classes] are “Open For Extension”.This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. 2. They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it. I realize that a good part of readers have read no further than that and stigmatized Robert Martin for using implementation inheritance. Well, it’s just an unfortunate naming. What follows is the elaboration of what he meant. And he’s quite clear about that: Abstraction is the Key. He demonstrates a simplistic example of a class depending directly on a concrete class: Client Server Client{ doSomeWork(){ ( Server())->run();}} class public function return new Obviously, when class will have to be replaced, is affected. So the moral of the story: introduce abstractions and let your clients depend on them, instead of concrete implementations. And it’s all about the , resulting in a bit of abstractions and quite a few of composable, loosely coupled and highly coherent implementations. Server Client correct decomposing of the problem space On a module level, this principle is applied best with an approach David Parnas described back in 1972. It enforces , while the Open-closed principle suggests extracting abstractions, thus enabling loose coupling. high cohesion Robert Martin, , , , 2003 2004 2013 2014 All the following years he has been striving to make clear his point of extending the behavior not via inheritance, but via swapping implementation of useful abstractions. Not very successfully: in 2017, . some still don’t get it Class parameterization I’ve listed two ways of introducing new classes without modifying existing code. The first one is using inheritance, which is discouraged, and the second one is extracting new interfaces so that they can be injected in a class. The third way is class parameterization, if I can call it so. It’s very close to introducing new abstractions, but it’s about injecting data instead of behavior. Consider the following example. I have a class that calculates employers’ salary. There could be different strategies, and this is reflected as the following (an example is simplified to stress the point): SalaryService{ = 0.07; class const TAX **private $salaryStrategy**;  

**public function** \_\_construct(SalaryStrategy $salaryStrategy)  
{  
    $this->**salaryStrategy** \= $salaryStrategy;  
}  

**public function** calculate()  
{  
    **return** $this->**salaryStrategy**\->calculate(**self**::**_TAX_**);  
} } So when a new strategy emerges, I won’t need to modify a class. It means that OCP is not violated with respect to this requirement. But then you’re told that a tax changed — so you need to reflect it in a code. Would it be a violation of the Open-closed principle? Sure, since you need to modify existing code. What options do you have? Simple constant doesn’t represent any behavior, it represents data. Though you still can inject it via an argument, say, constructor parameter: SalaryService SalaryService{ ; ; class private $salaryStrategy private $tax **public function** \_\_construct(SalaryStrategy $salaryStrategy, $tax)  
{  
    $this->**salaryStrategy** \= $salaryStrategy;  
    $this->**tax** \= $tax;  
}  

**public function** calculate()  
{  
    **return** $this->**salaryStrategy**\->calculate($this->**tax**);  
} } Violation of the Open-closed principle The code above doesn’t violate OCP in the context of a newly emerged requirement. Basically, there is no such thing like just “violation of the Open-closed principle”. It can be violated only for some set of requirements. So the first version of could have been aligned with the Open-closed principle for years, right until the moment when the tax changed. SalaryService Every time you need to implement new requirement and you modify existing code, it’s OCP violation. Of course, you can’t find out all your abstractions in advance — just because you can’t find out all the requirements in advance. So violating the Open-closed principle is OK — only if you’re extracting new abstractions, of course. Summing it up If any behavior, which is a part of some class, can change, then its implementation should hide behind an interface. This has a name already — it is . But it can’t come up purely mechanically, by extracting a couple of interfaces. It all starts with . loose coupling domain decomposing

Stories, News & Mentions about SALARYTDS

Salarytds’s Stories on HackerNoon