DoesQA makes it easy to build high-quality test coverage with reliable test automation rapidly. Automated testing how it

DoesQA

Starting Point: Where a Leader Begins Leadership manifests itself one way or another almost immediately. In my case, the managerial nature began to emerge in the second year of my professional path. First, it was expressed in understanding how to organize and optimize processes. My sensitive team leader noticed this, and I already had my own team for the next project. The climate within the team was friendly, and it showed me that leadership is quite an exciting job. Later on, I was surprised to read stories about tension and toxicity in other companies and realized how smoothly we managed to build bonds within the team. In a few years, I was given the opportunity to be the manager of the QA area, where I was involved in hiring. At the same time, I had to close the tasks of a business analyst, which allowed me to communicate closely with the client and develop my communication skills. Because the client was from the US, I became deeply involved in the study of Western business culture. I came to understand their way of thinking, values, the intricacies of communication, and how they respond to us and our culture in general. The skill of cross-cultural communication is a must-have and not only when working in a global company. You, as a leader, are simply obliged to have a broad outlook, which makes your toolkit more comprehensive. Why Leadership Feels Good I really enjoyed being a QA lead. First, I'm pretty good at testing, as far as my teammates’ feedback is concerned. In addition, there comes a certain point in your career when you are ready to pass on the gathered experience to others — it is a pity to keep it to yourself; therefore, it should live on via colleagues. After all, each stuffed cone is a specific lesson that translates into a solution. So, almost without noticing it, I began to grow my team and nurture each of them. The curious thing is that if you are a born leader, the circumstances are shaped so that you will certainly fulfill yourself. The main thing is to grab the opportunity by the tail on time. It feels good to choose tasks for yourself: put aside routine, monotonous things and plunge into non-trivial problems. Routine and repetition are present in any job, and these tasks are best for those who require practice, and here you need to have a clear idea of ​​​​who to delegate such tasks to. If we draw analogies, then the work of a leader is like sailing through a rough sea in a small boat that climbs the next wave. Each problem has an open end and many unknowns. And when in such conditions, you are surrounded by a team in which trust reigns, you can overcome any storm and manage to get pleasure at the same time. Interesting Because It's Difficult Communication is the most important yet hardest aspect of a leader's career. Here, again, the predisposition to interact with people plays an immense role. In my opinion, a good leader is an empathic human being who subtly feels, reads the emotions of people, and most importantly, knows how to handle them carefully. In pursuing this, corporate training on emotional intelligence really helped me a lot, and I use this knowledge daily. Understanding your team and indulging are not the same. The work is not about the satisfaction of any one side. This is a kind of waltzing around the team, client, and management, where a partner wants to achieve their specific goals. The leader’s mission in this dance is to build a system to make each one happy, which is my definition of project success. In other words, we do not have to set the same tasks, but we should all strive towards the same goal. Customers can also represent a challenge. I mean the ones that are not easy to do business with due to the human factor. This type of customer may be inclined to micromanagement, which is good for nothing at all times. You need to be able to build a process so that all participants are satisfied. At a professional level, leaders are often yes-men, which is now true for me as well. I believe that any proposal has the right and reason to exist, and I try to find positive aspects in them from the point of view of different team members. I guess, I don't argue my point of view as much as I should. But at the same time, the ability to listen and understand is one of the foundations of healthy teamwork. I Learn, Therefore, I Grow Analyzing all my experiences, perhaps the main lesson I learned is that the key to a project’s success is in that elusive client satisfaction. This is the foundation of the team and management’s contentment from work. I noticed that I used to think more like a QA than a manager: finding and reporting problems. In fact, my immediate task is to solve these. Overall, success stands on three pillars: team, client, and company. In this context, I should act as a facilitator for all parties. Understanding what the client values ​​implies a profound knowledge of their businesses and respective processes, especially those involved in the project. Awareness of what the team faces every day, at least at a basic level, demands insight into the technologies used on the project. If this is a software project, the manager must know its architecture, and how its components interact. This helps in problem identification and simple rapport within the team. Even a basic programming course may be required to capture the meaning of some jokes In general, I noticed that engineers respect those who have a good grasp of their business, and dislike those who pretend they do yet are incompetent. Therefore, it will be easier for a tech-savvy person to gain the trust of a team, but this does not mean that it should be difficult for a non-techie. Such a person should just be honest and brave enough to approach the situation with humor, doing the job in the best way possible. I also get that both techies and non-techies have the same respect for a job well done. The trust will come when the team sees that their work has become more organized and productive upon your arrival. I am the one responsible for the processes. If my letter remains unanswered for an entire day, I will not continue waiting for the sea weather. I need to reach out immediately and get a response, because any delay fails other people and is detrimental to the entire project, and, therefore, to the company's reputation. It took me some time to figure this out. Another important lesson is the urge for data security. Sometimes hackers happen to access the repository where the projects are located. One should not underestimate the capabilities of criminals and rely on chance. I take cybersecurity very seriously: providing effective protection universally is part of my work culture, my habit. Some might say I am overly serious about this issue, however, my vigilance has never let me down. As a leader, I do my best to ensure that my stance on this matter becomes the stance of the whole team without compromise. You Can't Win Alone Over the years, I devoted a lot of time to hiring and QA selection. Now I am actively engaged in hiring developers, but the method is pretty much the same overall. First of all, you need to determine the project needs, the entire amount of necessary resources, and the required competencies for specific tasks. Accordingly, we draw up a candidate profile, which then travels to recruiters. In this case, the quality of the interview and expertise of the interviewer are pivotal. Sometimes you need to dig deeper by asking the right questions. In addition to the technical base, an interview demands an ability to read between the lines, and pay attention, not only to what a person answers, but how one does it, how one reacts. When the top specialists appear to be toxic, harsh, or overly emotional, there will be no well-coordinated work or positive results. Visual contact is essential. By switching to remote, we conduct video interviews, that complete picture of the personality helps to form an opinion. That is, what is the impression of the conversation as a whole? Was it pleasant or tense? I like to start a talk by asking about the candidate’s career journey. Ambitions, dreams, accents, and degree of enthusiasm surface right away. I am always interested in how deeply a person comprehends their own role in the project. One of the hiring cornerstones is to involve the team in it. This is a guarantee that the newcomer will accurately match the vibe and the impression will incorporate different perspectives. That is, it is not enough to trust yourself — you need to trust your people’s perceptions. This is my major principle. Changing my mind is not hard for me at all. I always keep in mind I may be wrong, and that my solution may not be the best. Favorable Environment For A Leader To Grow No one needs a leader in a vacuum. In the development of a manager, the surroundings and people are at the core. I feel tremendous support from my team. Pleasing the client is not enough. You need to listen to your colleagues’ feedback and draw conclusions. For a novice manager, a systematic response is important — knowing how one succeeds and whether one is succeeding at all is vital. This leads us to the corporate culture within the company, its values, DNA, and ideals. I am lucky to work with open, honest people who are transparent in their words and actions. They create a unique atmosphere, and it is crucial for each person to contribute to it. We are each other's students and teachers at the same time. When there is no red tape or insurmountable walls, but instead a simple humanity, the leader evolves and inspires others to do the same. In this article, Anton Shashuk, Delivery Manager at , shares his own experience and path to engineering leadership. Innovecs

A Path to Engineering Leadership: Perks, Lessons, and Food for Thought 

LOOKING SOUTH.

There are quite a few rules/principles that get thrown around in the software world. Some that come to mind are , , , etc. I totally stand by all of them and believe our world would be a much better place if these principles are followed more. SOLID principles Design Patterns Do one thing and do it well The problem, however, is that those principles are quite abstract and at a very high level. During my code reviews, engineering discussions and writing of code, its tough to apply them directly. You wouldn’t know when you’re violating any/some of them. I thought of compiling a list of principles that are easier to apply. They are derivatives of the above mentioned ones. Let’s begin! 1. Do not build for the future I have found myself falling into this trap more times than I’m willing to admit. Let’s create a ParentClass (that will be extended by only 1 ChildClass), let’s store the history of user status changes (even though we need only the latest one now), etc. Don’t! After burning my fingers a couple of times, I found out I’m not the only one. There’s a principle called YAGNI: YAGNI- You Aren’t Going to Need It Martin Fowler has ; the gist of it is: a great piece on it We end up with three classes of presumptive features, and four kinds of costs that occur when you neglect yagni for them. Now, when engineers or project managers argue we need it in the future, I tell them YAGNI (and share the above link). might We needed to show the job application status of a job. We thought, let’s store the history of the statuses, Needless to say, we didn’t. Moreover, we started seeing duplicate jobs in some cases. Due to a programming bug, the SQL query was giving duplicates on production data. When I realized the root cause, I’m like An example: we might need it in the future. INNER JOIN I violated YAGNI 🤦‍♂️. 2. Do not copy-paste code Every time you copy and paste code (even if it’s just one line), you’re making a mistake. Do not copy-paste code. Create a private function and put the common code there. Create a common base class, or extract the common functionality into a module. In software, DRY is preferred over WET DRY- Don’t Repeat Yourself WET- We Enjoy Typing. “ on’t epeat ourself” — How many times do you see that there are similar codes in different parts of a system? The DRY principle, formulated by Andrew Hunt and David Thomas in their book that “ In other words, you must try to maintain the behavior of a functionality of the system in a single piece of code. D R Y The Pragmatic Programmer, states every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” On the other hand, when the DRY principle is not followed, this is known as WET solutions, which stands for either or Write Everything Twice We Enjoy Typing. — Oscar Salas Another way to look at this principle is to have a I have another piece on the lengths I went to have a single source of truth. Totally worth the effort. Single Source of Truth. I used metaprogramming in production. Recently, instead of copy-pasting a lot of raw SQL in my ORM, I created a small framework that takes in the params, and creates SQL queries based on that. That took longer than expected; because, you know, SQL. While writing the queries and fixing the SQL errors, I was regretting my decision. Nonetheless, I powered through. Weeks later, I had to add a simple clause in 7–8 SQL queries. Fastest change I have ever made. When the code worked in the first attempt, made me smile at the computer. WHERE complex 3. Code readability, not performance Optimize for code readability rather than for performance. As a software engineer, fresh in college, I took great pride in optimizing code (use fewer CPU cycles). I wish I had gotten this advice then: Programs must be written for people to read, and only incidentally for machines to execute. — Abelson & Sussman, Structure and Interpretation of Computer Programs the (premature) optimzations I have ever done have never ever solved (or partly helped) even one of the performance issues I have faced. Now, I solve for performance, when the profiler running in production tells me to, or when my apps are crashing with OutOfMemoryExceptions; not a moment before. All actually Make it correct, make it clear, make it concise, make it fast. In that order. — Wes Dyer Don’t write instead of . All modern compilers will generate the exact same output anyway. x << 1 x * 2 4. Delete unused code This is a corollary to both YAGNI and code readability. Delete unused code because you aren’t going to need it, and, nothing is much more readable than anything else! I always delete classes/functions/variables that aren’t being used. In Java (using the IDE) this is very easy to spot. In python (and other interpreted languages) I have to be more deliberate about code deletion. This means: always Don’t commit commented code. Delete commented code whenever you see it. Deleting directly unused code is easy. I take it a step further and delete old (unused) API endpoints and other functionality. Because that means I can delete the corresponding view, controller and serializer(s)! It’s not always easy to figure which endpoints are not being used anymore but it is always worth the effort. My Favourite Code refactor so far! By far my favourite story is : Engineers secretly hatched a plan to effectively deprecate IE 6, and secretly push this change without the necessary approvals from the management. A Conspiracy To Kill IE6 This banner caused IE 6 usage to suddenly drop drastically! These “Old YouTubers” This story isn’t all about deleting old code. It just illustrates my point very well. Go to the extra mile to delete code. first made the old code unused, then deleted the unused code! The best way you can contribute to an open source project is to remove lines of code from it. We should endeavour to write code that a novice programmer can easily understand without explanation or that a maintainer can understand without significant time investment. 5. Be deliberate with your naming Name your classes, methods, class variables and even local variables very semantically. Whenever you’re introducing a new name, stop and think for a few seconds. Name the symbol as per its behaviour. I follow a consistent naming pattern: Models should be singular. class User Objects of collections (Arrays, Sets) should be plural. List<User> users There is a world of difference between the methods and . Name your method as it behaves! get_user get_or_create_user This actually prevents me from violating the Single Responsibility Principle. If I need to name my class something of the form of I know I’m making a mistake. class DoesXAndY In my early open source days, I spent a lot of time renaming my variables achieving the desired functionality. I used to think . Now, when I read others’ code, I realize its importance. I don’t feel bad about being pedantic in code reviews: after “What a waste of time. The code is working” change num_users to number_of_users or user_count 6. Change one thing at a time I have done this mistake many times. I take the task of refactoring a part of the codebase. While refactoring, I realize these other things that are broken (as they always are). I fix them as well. Soon, I end up having a thousand line long PR! I needed to refactor the project’s Job model. It had a lot of related models. I guess the intent was to have a de-normalized schema. Instead, it was a tangled messed of bad data modelling. I knew how it should it look ideally. Naively, I created that schema and started writing migrations. So many dependant things broke. It was stressful for me and the entire team. Instead of 3 days and 1 engineer, it took 7 days and 2 engineers. Not to mention the un-needed stress and loss of faith. It was like opening a can of worms. In hindsight, I should have removed one dependant model at a time, rather than all at one go. Remove one model, migrate it, test it. Then, repeat this process a couple of times. “Change One Thing at a Time” extends to the entire engineering process, not just to the coding phase. It’s very common for companies to break up their monolith into smaller services as they grow and handle more scale. This process takes months and years. Not only does the code needs to be refactored, the teams need to be re-organized. Project structure, deployment process, everything needs to change. All this cannot be done in one huge change. If you every wonder how to do a change that seems like moving a mountain, now you know how to do it. Break the task down into smaller bite-sized chunks, and finish them one by one. At Apna, we do feature sprints rather than the usual fixed-days (1 week or 2 week) sprint. We build one feature, test it internally, and then release it in production. There is no point in clubbing 2–3 unrelated features in a release. Our sprints range from 3 to 4working days long. This gives us the much needed speed as a startup, and reduces the amount of stress during a release. 7. Write Dumb Code This is one of the most counter-intuitive thing I’ve learnt (rather, am learning). The following excerpt explains it perfectly: If, like me, you were once a Junior Dev, you may remember your first experience looking at a Senior Dev’s code and thinking, “I can write that. Why aren’t I a senior?” Yet I tried to write code like that for a long time, and I couldn’t. What was so mystifying about “Senior Dev” code was that I didn’t understand it, but that I could understand it immediately, it was fundamentally dumb, and it seemed like there had to be more to it. “Where’s the rest?” I remember thinking. “How does this do all of that?” not Since then I’ve learned all the names of all the principles and qualities of code that make it dumb: YAGNI, Single Responsibility Principle, DRY, Single Level of Abstraction Principle, low coupling, etc. And I’ve become a “Senior Dev” as well. The greatest lessons I’ve learned are that writing dumb code is actually hard, and that it pays exponential dividends to do so. — Why Senior Devs Write Dumb Code Kent Beck said it more provocatively: Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Kent Beck I have made the mistake myself of writing cool code like meta programming, but the real achievement would have been to get the same functionality without the “cool” code. In my defence, I did write a lot of comments. Phew, that’s a long list! Still, there are many more that I didn’t write down. I too forget to follow them sometimes. I do cut corners under time pressure. So, I wrote them down to remind myself. I have regretted violating any of the principles a few weeks/months later. These are rules of - you don’t follow them, but you’re always better off following them. always thumb have to The principles mentioned above are not necessarily applicable to all of software engineering. It is more inclined towards high level software projects- python/java, web/mobile apps. The stuff that I work on. Probably most of it wouldn’t be applicable in, say, LINUX kernel development, the GNU C/C++ compiler, etc. I want this post to be a perpetual work in progress- add, re-arrange and remove ideas from time to time. Reply to this post or for any suggestions/corrections. hit me up on twitter

Rules of Thumb for Software Engineering

GUI’s are hard to create. Luckily for us, we can often get away with making our code available through a command line interface. As you start writing more Haskell programs, you’ll probably have to do this at some point. This article will go over some of the ins and outs of CLI’s. In particular, we’ll look at the basics of handling options. Then we’ll see some nifty techniques for actually testing the behavior of our CLI. A Simple Sample To motivate the examples in this article, let’s design a simple program We’ll have the user input a . Then we’ll print the message to a file a certain number of times and list the user’s name as the author at the top. We’ll also allow them to uppercase the message if they want. So we’ll get five pieces of input from the user: message The filename they want Their name to place at the top Whether they want to uppercase or not The message The repetition number We’ll use for the first three pieces of information. Then we’ll have a for the other two. For instance, we’ll insist the user pass the expected file name as an argument. Then we’ll take an option for the name the user wants to put at the top. Finally, we’ll take a flag for whether the user wants the message upper-cased. So here are a few different invocations of the program. arguments and options command line prompt >> run-cli “myfile.txt” -n “John Doe”What message do you want in the file?Sample MessageHow many times should it be repeated?5 This will print the following output to : myfile.txt From: John DoeSample MessageSample MessageSample MessageSample MessageSample Message Here’s another run, this time with an error in the input: >> run-cli “myfile2.txt” -n “Jane Doe” -uWhat message do you want in the file?A new messageHow many times should it be repeated?asdfSorry, that isn't a valid number. Please enter a number.3 This file will look like: From: Jane DoeA NEW MESSAGEA NEW MESSAGEA NEW MESSAGE Finally, if we don’t get the right arguments, we should get a usage error: >> run-cliMissing: FILENAME -n USERNAME

Usage: CLIPractice-exe FILENAME -n USERNAME [-u]  Comand Line Sample Program Getting the Input So the most important aspect of the program is . We’ll ignore the options for now. We’ll print a couple messages, and then use the function to get their input. There’s no way for them to give us a bad message, so this section is easy. getting the message and repetitions getLine getMessage :: IO StringgetMessage = do  putStrLn "What message do you want in the file?"  getLine But they might try to give us a number we can’t actually parse. So for this task, we’ll have to set up a loop where we keep asking the user for a number until they give us a good value. This will be recursive in the failure case. If the user won’t enter a valid number, they’ll have no choice but to terminate the program by other means. getRepetitions :: IO IntgetRepetitions = do  putStrLn "How many times should it be repeated?"  getNumber

getNumber :: IO IntgetNumber = do  rep <- getLine  case readMaybe rep of    Nothing -> do      putStrLn "Sorry, that isn't a valid number. Please enter a number."      getNumber    Just i -> return i Once we’re doing reading the input, we’ll print the output to a file. In this instance, we hard-code all the options for now. Here’s the full program. import Data.Char (toUpper)import System.IO (writeFile)import Text.Read (readMaybe)

runCLI :: IO ()runCLI = do  let fileName = "myfile.txt"  let userName = "John Doe"  let isUppercase = False  message <- getMessage  reps <- getRepetitions  writeFile fileName (fileContents userName message reps isUppercase)

fileContents :: String -> String -> Int -> Bool -> StringfileContents userName message repetitions isUppercase = unlines $  ("From: " ++ userName) :  (replicate repetitions finalMessage)  where    finalMessage = if isUppercase      then map toUpper message     else message Parsing Options Now we have to deal with the question of how we actually . We can do this by hand with the function, but this is somewhat error prone. A better option in general is to use the library. We’ll explore the different possibilities this library allows. We’ll use three different helper functions for the three pieces of input we need. parse the different options getArgs Options.Applicative The first thing we’ll do is build a data structure to hold the different options we want. We want to know the file name to store at, the name at the top, and the uppercase status. data CommandOptions = CommandOptions  { fileName :: FilePath  , userName :: String  , isUppercase :: Bool } Now we need to parse each of these. We’ll start with the uppercase value. The most simple parser we have is the function. It tells us if a particular flag (we’ll call it ) is present, we’ll uppercase the message, otherwise not. It gets coded like this with the Options library: flag -u uppercaseParser :: Parser BooluppercaseParser = flag False True (short 'u') Notice we use in the final argument to denote the flag character. We could also use the function, since this flag is only a boolean, but this version is more general. short switch Now we’ll move on to the for the filename. This uses the helper function. We’ll use a string parser ( ) to ensure we get the actual string. We won’t worry about the filename having a particular format here. Notice we add some to this argument. This tells the user what they are missing if they don’t use the proper format. argument argument str metadata fileNameParser :: Parser StringfileNameParser = argument str (metavar "FILENAME") Finally, we’ll deal with the option of what name will go at the top. We could also do this as an argument, but let’s see what the option is like. An argument is a . An option on the other hand comes . We also add metadata here for a better error message as well. The piece of our metadata ensures it will use the option character we want. required positional parameter after a particular flag short userNameParser :: Parser FilePathuserNameParser = option str (short 'n' <> metavar "USERNAME") Now we have to combine these different parsers and add a little more info about our program. import Options.Applicative (execParser, info, helper, Parser, fullDesc,   progDesc, short, metavar, flag, argument, str, option)

parseOptions :: IO CommandOptionsparseOptions = execParser $ info (helper <*> commandOptsParser) commandOptsInfo  where    commandOptsParser = CommandOptions <$> fileNameParser <*> userNameParser <*> uppercaseParser    commandOptsInfo = fullDesc <> progDesc "Command Line Sample Program"

-- Revamped to take optionsrunCLI :: CommandOptions -> IO ()runCLI commandOptions = do  let file = fileName commandOptions  let user = userName commandOptions  let uppercase = isUppercase commandOptions  message <- getMessage  reps <- getRepetitions  writeFile file (fileContents user message reps uppercase) And now we’re done! We build our command object using these three different parsers. We chain the operations together using applicatives! Then we pass the result to our main program. If you aren’t too familiar with , and , we went over these a while ago on the blog. your ! functors applicatives Refresh memory IO Testing Now we have our program working, we need to ask ourselves how we . We can do manual command line tests ourselves, but it would be nice to have an automated solution. The key to this is the abstraction. test its behavior Handle Let’s first look at some basic file handling types. openFile :: FilePath -> IO HandlehGetLine :: Handle -> IO StringhPutStrLn :: Handle -> IO ()hClose :: Handle -> IO () Normally when we write something to a file, we for it. We use the handle (instead of the string literal name) for all the different operations. When we’re done, we close the handle. open a handle The good news is that the and streams are actually the exact same type under the hood! stdin stdout Handle stdin :: Handlestdout :: Handle How does this help us test? The first step is to abstract away the handles we’re working with. Instead of using and , we’ll want to use and . Then we take these parameters as arguments to our program and functions. Let’s look at our reading functions: print getLine hGetLine hPutStrLn getMessage :: Handle -> Handle -> IO StringgetMessage inHandle outHandle = do  hPutStrLn outHandle "What message do you want in the file?"  hGetLine inHandle

getRepetitions :: Handle -> Handle -> IO IntgetRepetitions inHandle outHandle = do  hPutStrLn outHandle "How many times should it be repeated?"  getNumber inHandle outHandle

getNumber :: Handle -> Handle -> IO IntgetNumber inHandle outHandle = do  rep <- hGetLine inHandle  case readMaybe rep of    Nothing -> do      hPutStrLn outHandle "Sorry, that isn't a valid number. Please enter a number."      getNumber inHandle outHandle    Just i -> return i Once we’ve done this, we can make the input and output handles parameters to our program as follows. Our wrapper executable will pass and : stdin stdout -- Library File:runCLI :: Handle -> Handle -> CommandOptions -> IO ()runCLI inHandle outHandle commandOptions = do  let file = fileName commandOptions  let user = userName commandOptions  let uppercase = isUppercase commandOptions  message <- getMessage inHandle outHandle  reps <- getRepetitions inHandle outHandle  writeFile file (fileContents user message reps uppercase)

-- Executable Filemain :: IO ()main = do  options <- parseOptions  runCLI stdin stdout options Now our library API takes the handles as parameters. This means in our testing code, we can pass to test the code. And, as you may have guessed, we’ll do this with files, instead of and . We’ll make one file with our expected terminal output: whatever handle we want stdin stdout What message do you want in the file?How many times should it be repeated? We’ll make another file with our input: Sample Message5 And then the file we expect to be created: From: John DoeSample MessageSample MessageSample MessageSample MessageSample Message Now we can write a test calling our library function. It will pass the expected arguments object as well as the proper file handles. Then we can compare the output of our test file and the output file. import Lib

import System.IOimport Test.HUnit

main :: IO ()main = do  inputHandle <- openFile "input.txt" ReadMode  outputHandle <- openFile "terminal_output.txt" WriteMode  runCLI inputHandle outputHandle options  hClose inputHandle  hClose outputHandle  expectedTerminal <- readFile "expected_terminal.txt"  actualTerminal <- readFile "terminal_output.txt"  expectedFile <- readFile "expected_output.txt"  actualFile <- readFile "testOutput.txt"  assertEqual "Terminal Output Should Match" expectedTerminal actualTerminal  assertEqual "Output File Should Match" expectedFile actualFile

options :: CommandOptionsoptions = CommandOptions "testOutput.txt" "John Doe" False And that’s it! We can also use this process to add tests around the error cases, like when the user enters invalid numbers. Summary Writing a command line interface isn’t always the easiest task. Getting a user’s input sometimes requires creating loops if they won’t give you the information you want. Then dealing with arguments can be a major pain. The library contains many option parsing tools. It helps you deal with flags, options, and arguments. When you're ready to test your program, you'll want to abstract the file handles away. You can use and from your main executable. But then when you test, you can use files as your input and output handles. Options.Applicative stdin stdout Want to try writing a CLI but don’t know Haskell yet? No sweat! Download our and get going learning the language! Getting Started Checklist When you’re making a full project with executables and test suites, you need to keep organized! Take our FREE to learn how to organize your Haskell with Stack. Stack mini-course

Getting the User’s Opinion: Options in Haskell

Not first class seats by Andrew Scofield on Unsplash Functions: the killer JavaScript feature we never talk about. is a very in-demand language today. It runs in a lot of places from the browser to embedded systems and it brings a non-blocking I/O model that is faster than others for some types of applications. What really sets JavaScript apart from the rest of scripting languages is its highly functional nature. JavaScript JavaScript has more in common with functional languages like than with C or Java. — Douglas Crockford in Lisp or Scheme JavaScript: the World’s Most Misunderstood Language It’s a widely publicised fact that Brendan Eich, when creating the first version of JavaScript, was actually told he would be able to build a . It turns out that Sun Microsystems had other ideas and this language needed to wear a coat of procedural syntax inherited from a C or Java-like language. Despite all the semicolons, at its heart JavaScript remains a functional language with features such as first-class functions and closures. Lisp, a list processing language like Scheme or common Lisp programming This post will focus on first-class functions and higher order functions. To read more about closures and how to leverage them to wield JavaScript’s functional powers, I’ve written the : following post _To use JavaScript to its full potential you have to embrace its strong functional programming base._hackernoon.com Ingredients of Effective Functional JavaScript: Closures, Partial Application and Currying First-class functions A language with first-class functions means that it treats functions like expressions of any other type. Functions are like any other object. You can pass them into other functions as parameters: function runFunction(fn, data) {return fn(data);} You can assign a function as a value to a variable: var myFunc = function() {// do something}; const myNewGenFunc = someParam => someParam; You can return a function: function takeFirst(f, g) {return f;} First-class functions in practice Cheap dependency injection In languages without first-class functions to pass a dependency in you usually inject an object. Here we can just pass functions around, which is great. For example in Java to run a custom sort on an ArrayList, we have to use which expects a object as a parameter (see ). In JavaScript we use ( ) which expects a function. This is a bit less verbose since in this case we’re just going to be implementing one method of the interface ArrayList#sort Comparator the Java API docs here Array#sort MDN reference here Comparator It gets even better with ES6 default parameter syntax. // in fetch.jsimport axios from 'axios'; export function fetchSomething(fetch = axios) {return fetch('/get/some/resource');} // in someModule.jsimport axios from 'axios'; import { fetchSomething } from './fetch'; const fetcherWithHeaders = axios({// pass some custom configs}); fetchSomething(fetcherWithHeaders).then(/* do something */).catch(/* handle error */); // in someOtherModule.js import { fetchSomething } from './fetch'; fetchSomething().then(/* do something */).catch(/* handle error */); Callbacks and non-blocking IO JavaScript’s default behaviour on IO is non-blocking. This means we tend to pass a lot of callbacks (until Promises came along at least). Being able to pass a function as a callback instead of an object on which we will run a method (like we would in say Java) means we can have terseness in callback-based code. For example in Node: const fs = require('fs'); fs.readFile('./myFile.txt', 'utf-8', function(err, data) {// this is a callback, it gets executed// once the file has been read}); More functional programming primitives that require first-class functions Being able to return a function and closures means we have access to things like partial application and currying. . Read more about those FP superpowers here It also means we can start creating higher order functions. Higher order functions A function is a higher order function if it takes a function as a parameter, or returns a function as its result. Both of these requirements rely on functions being first-class objects in a language. , and / are the functions present in JavaScript that map to classic higher order functions in other functional languages. map filter reduce reduceRight In other languages: map tends to be called map or transform filter is called select in some languages reduce and reduceRight are the fold left and right functions (also called accumulate, aggregate, compress or inject in different languages) In functional programming languages, there are no loops. When you need to do an operation like traversing a list or a tree, there are two predominant styles: recursion and higher order functions. Recursion relies on a function calling itself, usually on a different part of the parameter (list being traversed for example). That’s a topic for . another post Higher order functions are usually provided by the language. In ES6 JavaScript these functions are defined on the Array prototype. Array#map is used if we want to perform the same change on each member of the array. It takes the function that should be applied to each element of the array as a parameter. That function is passed as parameters. map (element, index, wholeArray) const myArr = [ 'some text', 'more text', 'final text' ]; const mappedArr = myArr.map( function(str) {return str.split(' ');}); console.log(mappedArr);// [ [ 'some', 'text' ], [ 'more', 'text' ], [ 'final', 'text' ] ] Array#filter allows us to pick which elements of the array should remain in the transformed list by passing a filtering function that returns a Boolean value (true/false). As for this functions is passed . filter map (element, index, wholeArray) const myArr = [ 5, 10, 4, 50, 3 ]; const multiplesOfFive = myArr.filter( function(num) {return num % 5 === 0;}); console.log(multiplesOfFive);// [ 5, 10, 50 ] Array#reduce is used to change the shape of the array. We provide more than 1 parameter to this function (in addition to the array we’re reducing). We pass a reducing function and optionally the initial value of to reduce with. The function is passed . is the value returned by the previous reduction, for the first iteration that means it’s either the initial value of the first element of the array. is the value in the array at which we’re at. reduce (prev, curr, index, wholeArray) prev curr The classic example is summing or concatenating. const myNumbers = [ 1, 2, 5 ];const myWords = [ 'These', 'all', 'form', 'a', 'sentence' ]; const sum = myNumbers.reduce( function(prev, curr) {return prev + curr;}, 0); console.log(sum); // 8 const sentence = myWords.reduce( (prev, curr) => {return prev + ' ' + curr;}); // the initial value is optional console.log(sentence);// 'These all form a sentence' If you want to learn more about the internal of , and or recursion, I’ve reimplemented them in a recursive style using ES6 destructuring in the following post: map filter reduce _The latest ECMA standard for JavaScript (ECMAScript 6) makes JavaScript more readable by encouraging a more declarative…_hackernoon.com Recursion in JavaScript with ES6, destructuring and rest/spread Higher order functions in practice No more loops Higher order functions allow us to get rid of the imperative loops that seem to be spread everywhere. var newArr = [];var myArr = [ 1, 2, 3 ]; for(var i = 0; i < myArr.length; i++) {newArr.push(myArr[i] * 2);} console.log(newArr); // [ 2, 4, 6 ] // nicer with `map`const doubled = myArr.map( x => x * 2 );console.log(doubled); // [ 2, 4, 6 ] The intent is just clearer with map. We can also extract the function so we’re making our code more readable and modular. double const double = x => x * 2;const doubled = arr.map(double); It reads like a book and that’s important because we write for humans not machines. Side-effect free programming higher order functions do not mutate the variable they are called on. This is good, because the loop-based approach using and changes it. It means if you pass a variable as a parameter, it’s not suddenly going to get changed by a function down the call stack. Array .push .pop // some random module// obviously no one actually does thisfunction doesBadSideEffect(arr) {return arr.pop();} // somewhere quite importantvar arr = [ 'a', 'b', 'c' ]; var joinedLetters = ''; for(var i = 0; i < arr.length; i++) {joinedLetters += arr[i];doesBadSideEffect(arr)} console.log(joinedLetters);// whoops 'ab'// even though the naming makes us// expect 'abc' Declarative Code Optimisations In some languages functions like are parallelised. That’s because we don’t actually need to know what’s in the rest of the array to compute this particular element’s new value. If we’re doing complex things in the mapping function then this sort of optimisation could be very useful. map Effective Functional JavaScript Use first-class and higher order functions to write nicer code more easily. It’s nice and declarative instead of imperative, say what you want done not how to do it This will enable you to compose your functions and write code that is extremely terse without losing readability. Remember to give this post some 💚 if you liked it. Follow me Hugo Di Francesco or @hugo__df for more JavaScript content :). Edit: 24/01/2017, rephrased “Callbacks and non-blocking IO” following Anton Alexandrenok ’s comments

DoesQA

does.qa

-- employees

Since n.d.

COMPANY RANKING

DOESQA

EVERGREEN INDEX #4092

DoesQA WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

DoesQA

does.qa

-- employees

Since n.d.

COMPANY RANKING

DOESQA

EVERGREEN INDEX #4092

RELATED COMPANIESRANK

STORIES ABOUT DOESQA

DoesQA WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!