Addingwellis in the IT Operations Industry

Addingwell

addingwell

10 must-know code snippets that can help QA professionals with bug triaging and identifying defects. Among the many responsibilities that define QA’s role, bug triage stands as a crucial process, sifting through reported issues and identifying those that demand immediate attention. To supercharge this pivotal stage of the lifecycle, QA needs powerful tools at their disposal— including code snippets that harbor a wealth of insights and efficiencies. software development . As a QA professional, these carefully selected snippets serve as your roadmap through complex codebases, aiding you in . Bug triage is intricate uncovering hidden defects and improving the overall software quality These code snippets will help with bug triage and bring you one step closer to achieving seamless software delivery. 1. Log Statements Log statements are essential for understanding the application's execution flow and behavior during different scenarios. By adding well-placed log messages throughout the code, developers and QA professionals can trace how the application processes data, functions, and events. Log statements provide insights into variable values, method calls, and potential errors. In a testing context, log messages can be used to track the sequence of events during test runs and identify any unexpected behavior that might require further investigation. print("Debug message: Something happened here.") Add log statements strategically throughout your code to track the flow and identify potential issues. 2. Stack Trace When an exception occurs in the code, a stack trace is generated, showing the sequence of function calls that led to the exception. The stack trace is invaluable for debugging, as it helps identify the exact location in the code where the exception occurred. This insight aids QA professionals in bug triage and understanding the root cause of an issue, allowing developers to fix the problem quickly. The stack trace also shows the context in which the error occurred, providing essential clues about the application's state during the exception. import traceback

try:

    # code that may raise an exception

except Exception as e:

    traceback.print_exc() Catch and print the stack trace when an exception occurs to understand the error's origin and context. 3. Assertion Assertions are sanity checks placed within the code to validate certain conditions or assumptions. They are invaluable during development and testing because they help catch errors early in the process. When an assertion fails, it immediately indicates that something unexpected has happened. During QA triage, identifying and analyzing assertion failures can help narrow down the problematic code section and highlight potential issues that need to be addressed. assert condition, "Error message" Use assertions to check if certain conditions are met, helping catch issues early in development or during testing. 4. Debugging Breakpoint Setting a debugging breakpoint allows developers and QA professionals to pause the execution of code at specific lines. This enables them to interactively inspect the state of variables and the program's flow at that particular point. It aids in understanding the logic and data flow, helping to identify bugs, incorrect values, or unexpected conditions. Breakpoints are especially helpful when the cause of a bug is not apparent and requires deeper investigation. import pdb

pdb.set_trace() Place breakpoints to pause the code execution at a specific line and inspect variables and execution flow interactively. 5. Logging Logging is a valuable practice for recording critical events, data, and errors during the application's runtime. Logs provide historical data that helps understand how the application behaves in various situations. During QA triage, log messages can be used to trace the sequence of events leading to an issue or identify patterns of failure. By analyzing the log information, QA professionals can discover patterns or recurring problems and share relevant details with developers for debugging and fixing. import logging

logging.basicConfig(level=logging.DEBUG, format='%(asctime)s - %(levelname)s - %(message)s') Configure logging to record important events and information while running the code. 6. Time Profiling Time profiling is used to measure the execution time of specific code sections or functions. It allows QA professionals to identify performance bottlenecks, such as slow-running functions or database queries. Profiling the code can reveal areas where optimizations are needed, ensuring the application runs efficiently and providing a better user experience. import time

start_time = time.time()

# Code to be profiled

print("Execution time:", time.time() - start_time) Measure the execution time of specific code sections to identify performance bottlenecks. 7. Network Requests (Python Requests library) In modern applications, interacting with APIs and web services is common. Using the Python Requests library simplifies making HTTP requests and handling responses. For QA professionals, this is crucial for validating APIs and ensuring that the application communicates correctly with external services. It helps identify issues related to network connectivity, server-side errors, or incorrect API responses. import requests

response = requests.get(url)

if response.status_code == 200:

    # Process successful response

else:

    # Handle error cases Use the Python Requests library to make HTTP requests and handle responses accordingly. 8. Database Query (Python SQLite) Database queries are fundamental when an application interacts with a database. For QA triage, database queries are essential to check data integrity, consistency, and accuracy. By executing queries and analyzing the results, QA professionals can identify issues like incorrect data storage, failed data manipulations, or data retrieval errors. import sqlite3

connection = sqlite3.connect("database.db")

cursor = connection.cursor()

cursor.execute("SELECT * FROM table_name WHERE condition")

result = cursor.fetchall()

connection.close() Perform database queries to check data integrity and troubleshoot issues with database interactions. 9. Data Validation Data validation is critical to ensure the input data is correct and adheres to the expected format or constraints. During QA triage, data validation functions help identify issues related to invalid or unexpected data that could lead to application crashes, incorrect outputs, or security vulnerabilities. Proper data validation prevents problematic data from propagating through the application and causing further issues. def is_valid_email(email):

    # Check email format

    return True if re.match(r"[^@]+@[^@]+\.[^@]+", email) else False Create validation functions to ensure input data meets certain criteria before processing. 10. Test Framework Assertion Test frameworks, like PyTest, provide a structured approach to writing and executing test cases. Assertions within test cases are used to verify expected outcomes and actual results. When a test fails, something is not functioning as intended. These assertions help in identifying regressions, code changes that unintentionally impact existing functionality, or uncovering new bugs. Test frameworks ensure that the application maintains its desired behavior over time and aids in maintaining software quality. import pytest

def test_function():

    assert result == expected_result, "Test failed, result didn't match the expected value." Use testing frameworks like PyTest to write and execute test cases, making it easier to identify functional bugs. Tackling Bug Triage with Launchable Bug Triage Intelligence with Launchable Bug triage is an essential part of the software development lifecycle. It calls for strategies and tools to efficiently sift through and address defects. The ten indispensable code snippets discussed in this article form a critical part of the QA professional's toolkit, aiding in tracing application execution, validating data, investigating bugs, and upholding software quality. However, it's important to remember that these snippets are just one part of your triage toolkit. Launchable empowers teams to with smart test observability, with a comprehensive view of test performance. By identifying flaky tests and leveraging historical data through machine learning, Launchable optimizes test selection, saving resources. handle bug triage Through historical data and ML algorithms, Launchable prioritizes tests based on execution time and bug-catching ability. This accelerates bug detection, leading to quicker issue resolution. Predictive analytics from Launchable assess bug impact via affected tests, aiding resource allocation and informed bug triage decisions. Fine-tune test suites by focusing on critical tests, curbing redundancy and optimizing resource usage. This boosts efficiency during bug triage and development. Streamline bug triage by pinpointing likely test failures, expediting the discovery process. Predictive analysis gauges bug impact, informing consequences of inaction.  Minimize resource wastage and maximize efficiency – triage bugs with confidence with Launchable. Also published here.

Streamlining Bug Triage: 10 Must-Have Code Snippets for QA Teams

স্ট্রীমলাইনিং বাগ ট্রিজ: QA টিমের জন্য 10টি অবশ্যই কোড স্নিপেট থাকতে হবে

Optimierte Fehlertriage: 10 unverzichtbare Code-Snippets für QA-Teams

Simplificación de la clasificación de errores: 10 fragmentos de código imprescindibles para los equipos de control de calidad

Rationalisation du tri des bogues : 10 extraits de code indispensables pour les équipes d'assurance qualité

बग ट्राइएज को सुव्यवस्थित करना: क्यूए टीमों के लिए 10 आवश्यक कोड स्निपेट

バグトリアージの合理化: QA チームに必須の 10 のコード スニペット

버그 분류 간소화: QA 팀을 위한 10가지 필수 코드 조각

Simplificando a triagem de bugs: 10 trechos de código essenciais para equipes de controle de qualidade

Оптимизация сортировки ошибок: 10 фрагментов кода, которые обязательны для команд контроля качества

Hata Tespitini Kolaylaştırma: Kalite Güvence Ekipleri için Sahip Olması Gereken 10 Kod Parçacığı

Hợp lý hóa việc phân loại lỗi: 10 đoạn mã phải có cho nhóm QA

简化错误分类：QA 团队必备的 10 个代码片段

Five Weeks in a Balloon by Jules Verne, is part of the HackerNoon Books Series. You can jump to any chapter in this book . Chapter XXVI here CHAPTER TWENTY-SIXTH. One Hundred and Thirteen Degrees.—The Doctor’s Reflections.—A Desperate Search.—The Cylinder goes out.—One Hundred and Twenty-two Degrees.—Contemplation of the Desert.—A Night Walk.—Solitude.—Debility.—Joe’s Prospects.—He gives himself One Day more. The distance made by the balloon during the preceding day did not exceed ten miles, and, to keep it afloat, one hundred and sixty-two cubic feet of gas had been consumed. On Saturday morning the doctor again gave the signal for departure. “The cylinder can work only six hours longer; and, if in that time we shall not have found either a well or a spring of water, God alone knows what will become of us!” “Not much wind this morning, master,” said Joe; “but it will come up, perhaps,” he added, suddenly remarking the doctor’s ill-concealed depression. Vain hope! The atmosphere was in a dead calm—one of those calms which hold vessels captive in tropical seas. The heat had become intolerable; and the thermometer, in the shade under the awning, indicated one hundred and thirteen degrees. Joe and Kennedy, reclining at full length near each other, tried, if not in slumber, at least in torpor, to forget their situation, for their forced inactivity gave them periods of leisure far from pleasant. That man is to be pitied the most who cannot wean himself from gloomy reflections by actual work, or some practical pursuit. But here there was nothing to look after, nothing to undertake, and they had to submit to the situation, without having it in their power to ameliorate it. The pangs of thirst began to be severely felt; brandy, far from appeasing this imperious necessity, augmented it, and richly merited the name of “tiger’s milk” applied to it by the African natives. Scarcely two pints of water remained, and that was heated. Each of the party devoured the few precious drops with his gaze, yet neither of them dared to moisten his lips with them. Two pints of water in the midst of the desert! Then it was that Dr. Ferguson, buried in meditation, asked himself whether he had acted with prudence. Would he not have done better to have kept the water that he had decomposed in pure loss, in order to sustain him in the air? He had gained a little distance, to be sure; but was he any nearer to his journey’s end? What difference did sixty miles to the rear make in this region, when there was no water to be had where they were? The wind, should it rise, would blow there as it did here, only less strongly at this point, if it came from the east. But hope urged him onward. And yet those two gallons of water, expended in vain, would have sufficed for nine days’ halt in the desert. And what changes might not have occurred in nine days! Perhaps, too, while retaining the water, he might have ascended by throwing out ballast, at the cost merely of discharging some gas, when he had again to descend. But the gas in his balloon was his blood, his very life! A thousand one such reflections whirled in succession through his brain; and, resting his head between his hands, he sat there for hours without raising it. “We must make one final effort,” he said, at last, about ten o’clock in the morning. “We must endeavor, just once more, to find an atmospheric current to bear us away from here, and, to that end, must risk our last resources.” Therefore, while his companions slept, the doctor raised the hydrogen in the balloon to an elevated temperature, and the huge globe, filling out by the dilation of the gas, rose straight up in the perpendicular rays of the sun. The doctor searched vainly for a breath of wind, from the height of one hundred feet to that of five miles; his starting-point remained fatally right below him, and absolute calm seemed to reign, up to the extreme limits of the breathing atmosphere. At length the feeding-supply of water gave out; the cylinder was extinguished for lack of gas; the Buntzen battery ceased to work, and the balloon, shrinking together, gently descended to the sand, in the very place that the car had hollowed out there. It was noon; and solar observations gave nineteen degrees thirty-five minutes east longitude, and six degrees fifty-one minutes north latitude, or nearly five hundred miles from Lake Tchad, and more than four hundred miles from the western coast of Africa. On the balloon taking ground, Kennedy and Joe awoke from their stupor. “We have halted,” said the Scot. “We had to do so,” replied the doctor, gravely. His companions understood him. The level of the soil at that point corresponded with the level of the sea, and, consequently, the balloon remained in perfect equilibrium, and absolutely motionless. The weight of the three travellers was replaced with an equivalent quantity of sand, and they got out of the car. Each was absorbed in his own thoughts; and for many hours neither of them spoke. Joe prepared their evening meal, which consisted of biscuit and pemmican, and was hardly tasted by either of the party. A mouthful of scalding water from their little store completed this gloomy repast. During the night none of them kept awake; yet none could be precisely said to have slept. On the morrow there remained only half a pint of water, and this the doctor put away, all three having resolved not to touch it until the last extremity. It was not long, however, before Joe exclaimed: “I’m choking, and the heat is getting worse! I’m not surprised at that, though,” he added, consulting the thermometer; “one hundred and forty degrees!” “The sand scorches me,” said the hunter, “as though it had just come out of a furnace; and not a cloud in this sky of fire. It’s enough to drive one mad!” “Let us not despair,” responded the doctor. “In this latitude these intense heats are invariably followed by storms, and the latter come with the suddenness of lightning. Notwithstanding this disheartening clearness of the sky, great atmospheric changes may take place in less than an hour.” “But,” asked Kennedy, “is there any sign whatever of that?” “Well,” replied the doctor, “I think that there is some slight symptom of a fall in the barometer.” “May Heaven hearken to you, Samuel! for here we are pinned to the ground, like a bird with broken wings.” “With this difference, however, my dear Dick, that our wings are unhurt, and I hope that we shall be able to use them again.” “Ah! wind! wind!” exclaimed Joe; “enough to carry us to a stream or a well, and we’ll be all right. We have provisions enough, and, with water, we could wait a month without suffering; but thirst is a cruel thing!” It was not thirst alone, but the unchanging sight of the desert, that fatigued the mind. There was not a variation in the surface of the soil, not a hillock of sand, not a pebble, to relieve the gaze. This unbroken level discouraged the beholder, and gave him that kind of malady called the “desert-sickness.” The impassible monotony of the arid blue sky, and the vast yellow expanse of the desert-sand, at length produced a sensation of terror. In this inflamed atmosphere the heat appeared to vibrate as it does above a blazing hearth, while the mind grew desperate in contemplating the limitless calm, and could see no reason why the thing should ever end, since immensity is a species of eternity. Thus, at last, our hapless travellers, deprived of water in this torrid heat, began to feel symptoms of mental disorder. Their eyes swelled in their sockets, and their gaze became confused. When night came on, the doctor determined to combat this alarming tendency by rapid walking. His idea was to pace the sandy plain for a few hours, not in search of any thing, but simply for exercise. “Come along!” he said to his companions; “believe me, it will do you good.” “Out of the question!” said Kennedy; “I could not walk a step.” “And I,” said Joe, “would rather sleep!” “But sleep, or even rest, would be dangerous to you, my friends; you must react against this tendency to stupor. Come with me!” But the doctor could do nothing with them, and, therefore, set off alone, amid the starry clearness of the night. The first few steps he took were painful, for they were the steps of an enfeebled man quite out of practice in walking. However, he quickly saw that the exercise would be beneficial to him, and pushed on several miles to the westward. Once in rapid motion, he felt his spirits greatly cheered, when, suddenly, a vertigo came over him; he seemed to be poised on the edge of an abyss; his knees bent under him; the vast solitude struck terror to his heart; he found himself the minute mathematical point, the centre of an infinite circumference, that is to say—a nothing! The balloon had disappeared entirely in the deepening gloom. The doctor, cool, impassible, reckless explorer that he was, felt himself at last seized with a nameless dread. He strove to retrace his steps, but in vain. He called aloud. Not even an echo replied, and his voice died out in the empty vastness of surrounding space, like a pebble cast into a bottomless gulf; then, down he sank, fainting, on the sand, alone, amid the eternal silence of the desert. At midnight he came to, in the arms of his faithful follower, Joe. The latter, uneasy at his master’s prolonged absence, had set out after him, easily tracing him by the clear imprint of his feet in the sand, and had found him lying in a swoon. “What has been the matter, sir?” was the first inquiry. “Nothing, Joe, nothing! Only a touch of weakness, that’s all. It’s over now.” “Oh! it won’t amount to any thing, sir, I’m sure of that; but get up on your feet, if you can. There! lean upon me, and let us get back to the balloon.” And the doctor, leaning on Joe’s arm, returned along the track by which he had come. “You were too bold, sir; it won’t do to run such risks. You might have been robbed,” he added, laughing. “But, sir, come now, let us talk seriously.” “Speak! I am listening to you.” “We must positively make up our minds to do something. Our present situation cannot last more than a few days longer, and if we get no wind, we are lost.” The doctor made no reply. “Well, then, one of us must sacrifice himself for the good of all, and it is most natural that it should fall to me to do so.” “What have you to propose? What is your plan?” “A very simple one! It is to take provisions enough, and to walk right on until I come to some place, as I must do, sooner or later. In the mean time, if Heaven sends you a good wind, you need not wait, but can start again. For my part, if I come to a village, I’ll work my way through with a few Arabic words that you can write for me on a slip of paper, and I’ll bring you help or lose my hide. What do you think of my plan?” “It is absolute folly, Joe, but worthy of your noble heart. The thing is impossible. You will not leave us.” “But, sir, we must do something, and this plan can’t do you any harm, for, I say again, you need not wait; and then, after all, I may succeed.” “No, Joe, no! We will not separate. That would only be adding sorrow to trouble. It was written that matters should be as they are; and it is very probably written that it shall be quite otherwise by-and-by. Let us wait, then, with resignation.” “So be it, master; but take notice of one thing: I give you a day longer, and I’ll not wait after that. To-day is Sunday; we might say Monday, as it is one o’clock in the morning, and if we don’t get off by Tuesday, I’ll run the risk. I’ve made up my mind to that!” The doctor made no answer, and in a few minutes they got back to the car, where he took his place beside Kennedy, who lay there plunged in silence so complete that it could not be considered sleep. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Jules Verne (2002). Five Weeks in a Balloon. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/cache/epub/3526/pg3526-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

One Hundred and Thirteen Degrees

I have always wondered what set of code to run in the background to make my app powerful and responsive, but I don’t really know how. Some time ago, I got to know about isolates and tried implementing them. And I should tell you, it was painful. But I recently discovered how easy it has become. So here it is. You might have heard about isolates but never really understood them. Or maybe you might have implemented isolates, but the code was always messy and tedious to write. In any case, this blog will guide you through the ups and downs of the Isolate history and the current and better implementation that you should follow. You might want to use the latest method, or you might want to use the old method after all, it’s all up to you. The basics This is how the defines Isolates Flutter Documentation An isolated Dart execution context. Did you understand anything? At least I did not. So let’s begin understanding Isolates and then we’ll write our own definition. So what do we need for Isolates Recipe? What are Isolates? Why do we need them? What is Event Handling? How to implement Isolates? And finally, what are Isolate Groups? We’ll start with the bigger picture of Isolates and see what it really means and go deep down and piece all the parts together to see how each part of it works together so that we can understand what Isolates really do and why we need them. What are Isolates? To really understand isolates, first we need to go further back and make sure we know the answer to these two questions: What is the difference between Processor Cores and Threads? Core is a physical hardware component whereas thread is the virtual component that manages the tasks of the core. Cores enable completion of more work at a time, while threads enhance computational speed and throughput. Cores use content switching but threads use multiple processors for executing different processes. What is the difference between concurrent and parallel processing? Concurrency is when two or more tasks can start, run, and complete in overlapping time periods. It doesn’t necessarily mean they’ll ever both be running at the same instant. For example, multitasking on a single-core machine. Parallelism is when tasks literally run at the same time, e.g., on a multicore processor. Let’s get back to Isolates. Dart uses the Isolate model for concurrency. Isolate is nothing but a wrapper around the thread. But threads, by definition, can share memory which might be easy for the developer but makes code prone to race conditions and locks. Isolates, on the other hand, cannot share memory and instead rely on message-passing mechanisms to talk with each other. If anything is difficult to comprehend, keep reading. I am sure, you’ll get it. Using isolates, Dart code can perform multiple independent tasks at once, using additional cores if they’re available. Each Isolate has its own memory and a single thread running an event loop. We’ll get to the event loop in a minute. Why do we need Isolates? Before we get into more detail, we first need to understand how async-await really works. void main() async {
  // Read some data.
  final fileData = await _readFileAsync();
  final jsonData = jsonDecode(fileData);

  // Use that data.
  print('Number of JSON keys: ${jsonData.length}');
}

Future<String> _readFileAsync() async {
  final file = File(filename);
  final contents = await file.readAsString();
  return contents.trim();
} We want to read some data from a file, decode that JSON, and print the JSON Keys length. We don’t need to go into the implementation details here but can take the help of the image below to understand how it works. When we click on this button , it sends a request to _readFileAsync, all of which is dart code that we wrote. But this function _readFileAsync, executes code using Dart Virtual Machine/OS to perform the I/O operation which in itself is a different thread, the I/O thread. This means, the code in the main function runs inside the main isolate. When the code reaches the _readFileAsync, it transfers the code execution to I/O thread and the Main Isolate waits until the code is completely executed or an error occurs. This is what await keyword does. Place Bid Now, once the contents of the files are read, the control returns back to the main isolate and we start parsing the String data as JSON and print the number of keys. This is pretty straight forward. But let’s suppose, the JSON parsing was a very big operation, considering a very huge JSON and we start manipulating the data to conform to our needs. Then this work is happening on the Main Isolate. At this point of time, the UI could hang, making our users fustrated. What is Event Handling? As we discussed, Isolate is a wrapper around thread and each Isolate has an event loop executing events. These events are nothing but what happens when we use the application. These events are added in a queue which then the Event loop takes in and processes. These events are processed in the first-in-first-out fashion. The image below is just an example. Let’s use this code again for understanding event handlers. We already know what is happening in this block. void main() async {
  // Read some data.
  final fileData = await _readFileAsync();
  final jsonData = jsonDecode(fileData);

  // Use that data.
  print('Number of JSON keys: ${jsonData.length}');
}

Future<String> _readFileAsync() async {
  final file = File(filename);
  final contents = await file.readAsString();
  return contents.trim();
} Our apps start and it draws the UI (Paint Event) is pushed on to the queue. We click on the button and and file handling code starts. So the Tap Event is pushed in the queue. After it is complete, let’s suppose the UI is updated, so again the Paint Event is pushed in the queue. Place Bid Now because the our logic for handling the file and JSON was very small, the UI doesn’t stutter or jank. But let’s, for a while, imagine again that out code for handling file was huge and it takes a lot of time. Now the event queue and the event loop looks similar to this image below. Now that the main isolate takes a lot of time to actually process that event, our animation or UI might hang and irritate your users, causing huge dropoffs. This is where spawning a new isolate or a worker Isolate comes in. How to implement Isolates? All our dart code in the flutter app runs in isolate. Whether it is a main isolate or a worker isolate is up to you. The main isolate is created for you and you don’t have to do anything else here. The main function starts on the Main Isolate. Once we have our main function running, we can start spawning new isolates. So there’s 2 ways of implementing Isolates, the short and new method or the long and old method. We can use either, depending on the use case. Let’s start with the already existing method. As we had already discussed, Isolates, unlike threads, don’t share memory. This is done so as to prevent race conditions and locks. But the communication between Isolates is done using message passing. These messages are primitives and you can check out the whole list of objects that can be passed between isolates . here To pass messages, Dart provides us with Ports. SendPort and ReceivePort. Since we’re discussing the old method for spawning Isolates, we need to know that isolate methods need to be top-level or static functions. Here is the to the code if you want to follow along. link Future<String> startDownloadUsingOldIsolateMethod() async {
  const String imageDownloadLink = 'this is a link';
  // create the port to receive data from
  final resultPort = ReceivePort();
  // spawn a new isolate and pass down a function that will be used in a new isolate
  // and pass down the result port that will send back the result.
  // you can send any number of arguments.
  await Isolate.spawn(
    _readAndParseJson,
    [resultPort.sendPort, imageDownloadLink],
  );
  return await (resultPort.first) as String;
} What does this code do: Here we create an instance of RecievePort to receive data. Remember this is the old method for spawning Isolates. It can be a little long but it is necessary to know the details. We create a Worker Isolate on the Main Isolate using Isolate.spawn and pass down a top-level function that runs the blocking code. We also pass down a list of arguments, the first one, SendPort which will be used to send the data from the worker Isolate, and the second is the download link. We wait till the new Isolate has been spawned. We then wait for the result, which is some form of a String and use it however we want. This data can be anything from list of object. this ResultPort.first uses a stream subscription behind the screen and waits for the data from the worker isolate to be pushed onto it. As soon as the first item arrives, we return the result. This is the _readAndParseJson function that receives the argument and runs the worker isolate code. This is a dummy function that does nothing but delays the control for 2 seconds and then exits. The exit function terminates the current isolate synchronously. Certain checks are performed before sending the data back to the calling isolate and the data is sent back using the SendPort. // we create a top-level function that specifically uses the args
// which contain the send port. This send port will actually be used to
// communicate the result back to the main isolate

// This function should have been isolate-agnostic
Future<void> _readAndParseJson(List<dynamic> args) async {
  SendPort resultPort = args[0];
  String fileLink = args[1];

  String newImageData = fileLink;

  await Future.delayed(const Duration(seconds: 2));

  Isolate.exit(resultPort, newImageData);
} Although this functions correctly but we have not handled any errors which can be thrown from the worker isolate or any error which can occur while spawning a new isolate. // Error Handling
Future<String> startDownloadUsingOldIsolateMethodWithErrorHandling() async {
  const String imageDownloadLink = 'this is a link';
  // create the port to receive data from
  final resultPort = ReceivePort();
  // Adding errorsAreFatal makes sure that the main isolates receives a message
  // that something has gone wrong
  try {
    await Isolate.spawn(
      _readAndParseJson,
      [resultPort.sendPort, imageDownloadLink],
      errorsAreFatal: true,
      onExit: resultPort.sendPort,
      onError: resultPort.sendPort,
    );
  } on Object {
    // check if sending the entrypoint to the new isolate failed.
    // If it did, the result port won’t get any message, and needs to be closed
    resultPort.close();
  }

  final response = await resultPort.first;

  if (response == null) {
    // this means the isolate exited without sending any results
    // TODO throw error
    return 'No message';
  } else if (response is List) {
    // if the response is a list, this means an uncaught error occurred
    final errorAsString = response[0];
    final stackTraceAsString = response[1];
    // TODO throw error
    return 'Uncaught Error';
  } else {
    return response as String;
  }
} Everything is pretty same here, we just have added error handling here. What this code does is: We add errorsAreFatal to true while spawning a new isolate to make sure that the Main Isolate is aware of any errors. We assign the SendPort for onExit and onError handlers to make sure that if any errors that occur during exiting or spawning. We also add a try-catch block while spawning a new isolate to make sure that if any error occurs during spawning, we catch that and stop this operation, altogether. If the spawning is successful and some data do come from the worker isolate, we need to check if it’s error or not. If the message sent back is null, this means the isolate exited without any message, and an error has occurred. If the response is a list, this means the worker Isolate has sent back an error and a stacktrace. Else this is a successful transaction. This does seem like an overkill if we wanted to do just one-off message passing. One message and close the Isolate. Everytime you wanted to spawn a new isolate you’ll have to write the same code again. Since the Isolate logic is pretty custom. Every time you might want to pass in some different arguments and it would be very tedious. This is why a new method was devised for one-off transactions. The new method: Isolate.run // Isolates with run function
Future<String> startDownloadUsingRunMethod() async {
  final imageData = await Isolate.run(_readAndParseJsonWithoutIsolateLogic);
  return imageData;
}

Future<String> _readAndParseJsonWithoutIsolateLogic() async {
  await Future.delayed(const Duration(seconds: 2));
  return 'this is downloaded data';
} This is all there is for the new method. We spawn a new Isolate using the run method which abstracts out all the granular details and the error handling and saving you a lot of time. This helps in spawning, error handling, message passing and terminating the Isolate all using these few little lines of code. One thing to note here is that the function _readAndParseJsonWithoutIsolateLogic, does not contain any custom logic for the Isolate. No ports, no arguments. When to use the new Run method and when to use the old spawn method? These examples above shows message passing that happens only 1 time. So run method should be used. It greatly reduces the code lines and test cases. But if you want to create something that needs multiple messages to be passed between the Isolates, we need to use the old method. An example of this could be when you start downloading a file on a worker isolate and want to show the progress of the download on the UI. This means the progress count needs to be passed again and again. Isolate.spawn() With this, we need to implement the whole SendPort and ReceivePort for message passing and the custom logic for receiving the arguments and sending the progress back to the main Isolate. What are Isolate Groups? So, we already know how Isolates passes messages to each other. But let’s assume, the message we are passing is a huge JSON. Before Dart 2.15, this huge object passing, could involve stutter in UI. This is because, we already know that Isolate has some memory, and when one Isolate passes an object to the other, that object had to be deep copied. This meant, a lot of time for copying the object to the main Isolate which can cause a jank. To avoid this circumstance, Isolates were reworked and Isolate Groups were invented. Isolate Groups, meaning a group of isolates, which share some common internal data structures representing the running application. This means each time a new Isolate is spawned, new internal data structures don’t need to be constructed again. Because they share them together. Don’t confuse these internal data structures with the mutable objects. The Isolates still can’t share this memory with each other. Message passing is still needed. But, because Isolates in the same Isolate group, share the same heap, this means spawning a new Isolate is 100 times faster and consume 10–100 times less memory. An example is a worker isolate that makes a network call to get data, parses that data into a large JSON object graph, and then returns that JSON graph to the main isolate. Before Dart 2.15, that result needed to be deep-copied, which could itself cause UI jank if the copy took longer than the frame budget. This means that the main Isolate can receive this JSON in almost constant time. And sending messages is now approximately 8 times faster. The good news is that, if you’re using Flutter version greater than 2.8, you don’t need to do anything to use these advancements. Hope you liked the understanding of Isolates. If you have any doubts, please comment. Reference for this code: https://github.com/DhruvamSharma/NFT-Material3?embedable=true Also published . here

Running Parallel Code in Flutter With Isolates

We've recently announced that WunderGraph is now fully open source. Today, we'd like to explain how you can leverage our API Developer Framework to add Edge Caching to your GraphQL APIs without locking yourself into a specific vendor. Caching GraphQL on the Edge should be vendor-agnostic. Services like Akamai and GraphCDN / Stellate offer proprietary solutions to solving this problem.
We'll compare the different approaches and their tradeoffs. Why did we create proprietary GraphQL CDN solutions A good question to start with is why we've created proprietary GraphQL CDN solutions in the first place. Most GraphQL implementations ignore how the web works The problem with most GraphQL implementations is that they don't really use the "platform" they are operating on. By platform, I mean the web, or more specifically HTTP and the REST constraints. The web has a lot to offer if you're using it in the right way. If read requests (Queries) were using the GET verb, combined with Cache-Control Headers and ETag, Browsers, CDNs, Cache Servers like Varnish, Nginx, and many other tools could handle Caching out of the box. You wouldn't really need a service that understands GraphQL. However, the reality is that most GraphQL APIs make you send Queries over HTTP POST. Cache-Control Headers and ETags don't make sense in this case, as all participants on the web think we're trying to "manipulate" something. So, we've created Edge Caching solutions that rewrite HTTP POST to GET and are capable of invalidating in very smart ways. By analyzing Queries and Mutations they're able to build up a cache and invalidate Objects as mutations flow through the system. Limitations and Problems of GraphQL CDNs / Edge Caches A GraphQL CDN creates a secondary source of truth As discussed in the constraint by Fielding, intermediaries can be used to implement a shared cache to improve the latency of requests. The problem I see with "smart" GraphQL Edge Caches is that they look into the GraphQL Operations to figure out what to cache and what to invalidate. Some GraphQL CDN implementations even allow you to use their API to invalidate objects. Layered System What sounds very smart creates a huge problem, you're building a second source of truth. Before using the GraphQL CDN, all you've had to do is implement your resolvers. Now, you've got to think about how to invalidate the CDN. Even worse, you're now programming against a single vendor and their implementation, coupling your application to a single service provider. You can't just switch easily from one GraphQL CDN provider to another. Contrary to REST/HTTP APIs, there's no standard on how to Cache GraphQL APIs, hence every implementation will be different. Another issue is that we're creating a secondary source of truth. Imagine we're putting a GraphQL CDN in front of the GraphQL API of GitHub to cache the Issues for a repository. If we're using "smart" Cache invalidation using Mutations, we're not able to update the cache if a user is bypassing our CDN and uses the GitHub API directly. A GraphQL CDN really only works if 100% of the traffic flows through the system. Your GraphQL Edge Cache won't work on localhost or in your CI/CD Testing takes up a huge part of software development, and we definitely want to have a great Developer Experience when building our APIs. Using a proprietary, cloud-only, Caching solution means that we're not able to test it locally or from within our Continuous Integration systems. You'll be developing on your local machine without the CDN, only to find out that something behaves weirdly when you're using the CDN in production. If we were using standardized caching directives, we'd be able to use any Cache Server, like Nginx or Varnish within our CI/CD pipeline to test our APIs. Proprietary GraphQL CDNs impose a vendor lock-in problem As mentioned earlier, there's no specification for how GraphQL Caching should work. Every implementation is different, so you're always tied to a specific vendor. They might get broke, they might get acquired, they might cancel their service, and they might change their pricing model. In any case, it's a risk that needs to be managed. A GraphQL CDN can introduce cross-origin requests Depending on the setup, adding a GraphQL CDN to your architecture could mean that your browser-based applications have to make cross-origin requests. That is, when your application is running on and your GraphQL CDN runs on , the browser will always make an extra Preflight request. It's possible to cache the Preflight request, but this still means that we'd have to do at least one extra request on the initial page load. example.com example.cdn.com A GraphQL CDN might not work well for authenticated Requests with Server Side Rendering (SSR) Let's say your application requires your users to be logged in, but you still want to be able to apply to cache. Aside from that, you'd also like to implement Server-Side Rendering (SSR). In the ideal scenario, you'd have your users log into your authentication server, which sets a cookie on your apex domain so that you're logged in on all subdomains. If your CDN is running on a different domain, it's going to be impossible to server-side render a page as the browser will not send the user's cookie to the CDN domain. Luckily, some providers offer custom domains, so cookie-based authentication might still work for you. Invalidating Deeply Nested GraphQL Operations might not work Here's an example of a GraphQL Operation that invalidates easily. mutation UpdateProfile {
    updateProfile(update: {id: 1, name: "Jannik"}) {
        id
        name
        friendsCount
    }
} If you've previously Queried the user with id 1, you can invalidate all records with that id and invalidate the following Query: query {
    profile(id: 1){
        id
        name
        friendsCount
    }
} Let's make it a bit more complex and query for all your friends: query {
    me {
       friends {
            id
            name
        }
    }
} Now, you made some good friends at the last conference. Let's add them: mutation AddFriend {
    addFriends(where: {user:{hasConnection: {conferences: {id: {eq: 7}}}}}){
        id
        name
    }
} We've now added all users as friends that had visited a conference whose id equals 7. At this point, we don't get back all the data when we query again for all your friends because the cache can't know that the mutation has invalidated the cache for the query. addFriends friends At this point, you've got to start adding response tagging, surrogate keys, or analyzing the GraphQL return types to make your invalidation strategy "smarter". We'll pick up this topic again after the benefits. Benefits of using a GraphQL CDN / Edge Cache When there's a cost, there are also benefits! Using a GraphQL CDN means, you don't have to change much of your application. In an ideal scenario, you simply change the URL of the GraphQL Server and everything should work. You also don't have to deploy and configure any tooling. You're buying a ready-to-use service that just works. Despite the problems discussed earlier, a GraphQL CDN can probably improve the performance of many applications. When not to use a GraphQL CDN As discussed in the section on Cache Invalidation, building a smart CDN service that doesn't know anything about your GraphQL Backend is actually extremely hard. The problem lies in the fact that the Backend is the source of truth, but doesn't share all this information with the Cache. In fact, if you're running into such issues where invalidation becomes hard, you might want to apply caching at a different level, inside the resolvers, or even one level below, at the entity level, using the DataLoader pattern. Additionally, if your data is expected to change frequently, it might make not much sense for you to cache at the Edge. Another big underrated flaw is that the invalidation of a distributed cache is eventually consistent. This means you serve stale content after a mutation for a short period of time. If you don't respect that in your architecture it has the potential to break the business logic of clients. Client (US) -> Query all posts to fill the cache
Client (US) -> Run mutation to update the post with ID:1
System fires a web-hook to a third-party service in FRA
Client (FRA) -> Query all posts -> stale content This is not GraphQL specific but with HTTP Caching the semantics are better understood. In summary, don't use a GraphQL CDN if you need write-after-read consistency. If your requirement is to support write-after-read consistency, there are multiple solutions to the problem. One is to not cache at the Edge, but rather at the application layer. In this case, you'd trade latency for consistency, which can be a good trade. Another way of solving the problem is by distributing the state across the edge and sharding the data based on location. This model of sharding is not always possible, but if the shared state is only used across groups of users in the same location, this solution could work very well. One example of this is Cloudflare Workers + Durable Objects, which gives you a simple Key-Value store that is persisted in a specific location, meaning that all users close to that one location can have a consistent state at low latency. When a GraphQL Edge Cache makes the most sense If you've got a single GraphQL API, and this API is the only API your frontend is talking to, you fully own this API and no traffic is bypassing your Cache, then such a CDN might actually make sense. Otherwise, I doubt you get the results you're expecting, especially not with the extra costs discussed earlier. WunderGraph - An Alternative Approach to GraphQL Edge Caching without vendor lock-in We've discussed the pros and cons of GraphQL CDNs, now I'd like to propose another approach that makes you stay vendor independent. When it comes to solving problems, sometimes it's smart to be dumb. I think a Cache can be a lot smarter when it's dumb and playing by the rules of the web, and that's exactly what we're doing with WunderGraph. and can be deployed everywhere. Our solution is Open Source How does it work? I've been working with GraphQL for many years now, and I've realized that when we deploy an application that uses GraphQL APIs, I've never seen the application change the GraphQL Operations at runtime. What applications do at runtime is change the Variables, but the Operations usually stay static. So, what we've done is, we've created a GraphQL to JSON-RPC compiler, which treats GraphQL Operations like "Prepared Statements", you've probably heard of the term from using a database. When first using a SQL statement, you send it to the Database and get back a handle to "execute" it later. Subsequent requests can now execute the Statement just by sending the handle and the variables. This makes the execution a lot faster. Because we're not changing GraphQL Operations at runtime, we can actually do this "compilation" step during development. At the same time, we're replacing HTTP POST for Queries with HTTP GET, while sending the Variables as a Query Parameter. By sending GraphQL Queries via JSON-RPC with HTTP GET,
we're able to automatically enable us to use Cache-Control Headers and ETags. And that's the whole magic of WunderGraph's Caching Story. We don't build a "smart" Cache. We don't cache Objects, and we don't have to build complex invalidation logic. We simply cache the response of unique URLs. For each Operation, you can define if it should be Cached and for how long. If a response might change frequently, you can also set the Cache time to 0, but configure "stale-while-revalidate" to a non-negative number. The client will automatically send the request to the origin with the ETag, the server will either send a refreshed response or 304, not modified. It's a very dumb approach. If the cached value is expired or stale, we're asking the origin if they have an update. Depending on the configuration, that might create a few more requests to the origin, but we're also not creating a second source of truth, or have to deal with the complexity of managing cache invalidation tags for nested objects. It's similar to using Change Data Capture (CDC) as a source for Subscriptions vs. simple Polling. CDC can get extremely complex to get right, while simple server-side Polling might work just fine most of the time. It's simple and robust. There's really not much we've invented here, all this is standard Caching behavior and any service, like Cloudflare, fastly, Varnish or Nginx supports it out of the box. There's a standard for how all the participants of the web treat Cache-Control and ETag headers, we've simply implemented this standard. By removing GraphQL from the equation, we've made it compatible with the web. If you build tools for the web, you should respect how the web is built, otherwise, you're creating more problems than you're solving. Additional Benefits of the WunderGraph GraphQL Caching Approach It's not just CDNs and Servers who understand the Cache-Control and ETag Headers. Browsers also automatically cache and invalidate your responses, without adding a single line of code. Additionally, because we've removed GraphQL from the runtime, we've automatically reduced the attack surface of our application. If our frontend doesn't change GraphQL Queries at runtime, why expose an API that allows you to do so? Limitations of the JSON-RPC Caching Approach One of the limitations of this approach is that we're no longer able to use regular GraphQL Clients, as they'd expect us to send GraphQL Operations over HTTP POST, and Subscriptions over WebSockets. That's not an issue for new projects, but might be a blocker for existing applications. Btw. we've got an internal RFC to add a compatibility mode, allowing e.g. Apollo client / urql, etc. to work with WunderGraph through an Adapter. If you're interested, please let us know. That said, using plain JSON-RPC would be very inconvenient. That's why we're not just compiling GraphQL to JSON RPC, but also generating fully type-safe clients. One such client-side integration is the , making it super easy to use WunderGraph with NextJS, including Server-Side Rendering, Authentication, File Uploads, etc... NextJS package Another limitation, as of now, is that you have to self-host WunderGraph. We're working on a hosted Serverless solution, but as of now, you'd have to deploy and run it yourself. While it might not be super convenient, this also comes with an advantage: WunderGraph is Apache 2.0 licensed, you can run it anywhere. How can you deploy WunderGraph Now that we've discussed the pros and cons of the WunderGraph approach to caching, let's see how we can deploy WunderGraph to achieve good Caching results. First, you don't have to deploy WunderGraph globally. It's possible to run it close to your origin, e.g. the (micro-) services that you'd like to use. In this scenario, it's possible to run WunderGraph as an Ingress to your other services. The architecture of this scenario looks like this: Client -> WunderGraph Server -> Origin Deploy WunderGraph with Nginx or Varnish as an additional Caching Layer If you're deploying WunderGraph close to the origin, it will automatically add the required Cache-Control & ETag Headers. This setup might already be enough for your scenario. However, in some scenarios, you'd like to add another layer of Caching Servers. This could be e.g. a cluster of Nginx or Varnish servers, placed in front of your WunderGraph server. Architecture updated with this scenario: Client -> Cache Server -> WunderGraph Server -> Origin Deploy WunderGraph with Cloudflare or fastly as an Edge Cache Depending on where your users are, a centralized Caching Layer might not be sufficient for your use case. In this scenario, you can use services like Cloudflare (Workers) or fastly, to add a globally distributed GraphQL CDN / Edge Cache. What's important to note here is that you're not tied to a specific solution. As mentioned before, we're using standardized Cache-Control directives, supported by all Cache Server solutions, so you're not tying yourself to a specific vendor. Updated Architecture: Client -> CDN -> WunderGraph Server -> Origin Deploy WunderGraph directly on the Edge, using fly.io Another option is to deploy WunderGraph directly on the Edge, removing the need for an additional Caching Layer. Services like allow you to deploy Containers as close to your users as possible. The architecture of this scenario looks like the following: fly.io Client -> WunderGraph Server (on the Edge) -> Origin Deploying a service on the Edge is not always beneficial There's one important point I'd like to make that applies to all solutions mentioned in this post. If we're deploying a workload on the Edge, this service will be very close to the users, which is generally a good thing. At the same time, depending on where on the "Edge" we're processing a request, there might be a random latency between ~0-300ms to your origin server(s) per roundtrip. If we have to do multiple roundtrips to fetch the data for a single client request, this latency can add up. As you can see, it's not always beneficial to the overall performance to have logic running on the edge. There's one more thing! This solution works for GraphQL, REST, gRPC, and other Protocols as well! You've heard that right. WunderGraph is not just about GraphQL origins. We support a wide array of upstream protocols, like REST, gRPC (coming soon!), and Databases like PostgreSQL, MySQL, Planetscale, etc... WunderGraph ingests all your services and creates a "Virtual Graph", a GraphQL Schema representing all your services. The Caching layer we've described above does not just work for GraphQL origins, but all services that you've added to your Virtual Graph. This means, you're able to apply one unified layer of Authentication, Authorization, and of course Caching to all your APIs. From our experience, it's rarely the case that you're connecting a frontend to a single GraphQL server. Instead, you're probably going to connect it to many services, which is what we're trying to simplify, and caching is one part of the story. Conclusion We've discussed various options to improve application performance with different kinds of Caching systems. There are ready-to-use solutions that come with simplicity but also lock you into specific vendors. With WunderGraph, we're trying to offer an Open Source alternative that's based on standards and implemented by many tools and vendors, so you're able to choose the best-of-breed solution for your situation. If you're looking into adding Caching to your stack, we'd love to talk! or . Join us on Discord connect on Twitter Also published . here

How to Leverage Open Source GraphQL CDN/Edge Cache With Cloudflare, Fastly, and fly.io

If you're reading this, you probably know what a CI/CD pipeline is. If you don't, no big deal -- it's just yet another acronym. CI/CD short for "continuous integration and continuous delivery", which when we boil it down, simply means that everything between your git commit and a deployment works auto-magically so you can rest your fingers and watch some Netflix. In this example, I'm going to be focusing on deploying a static HTML website, but you really could do this for any sort of web application front-end. We will be highlighting how to do this using AWS, Terraform and Gitlab. Let me just explain real quick why we'd want to do this. First, this makes your life easier. You write the code, you make a commit, push, and your pipeline deletes old files from your S3 bucket, uploads the new files, sets permissions, and then invalidates your CloudFront distribution so that all you have to do is go look at your changes in production. Second, it removes human error. You can't forget to upload files or invalidate a CF if your code does it for you. Third, it speeds up your deployments because you no longer have to go ahead and do things manually. For all of these reasons, I always set up a pipeline for all of my personal and professional projects. Enough of me rambling; let's get to work. Prerequisites A account GitLab An account AWS is installed Terraform A account Keybase Set up the infrastructure I like to make things as easy and reproducible as possible, so we'll be using Terraform to build out the infrastructure. If you don't have Terraform installed, then you didn't read the prerequisites (tsk tsk...) and I'm going to need you to install it. For the website's infrastructure, all we'll need is an S3 bucket and a CloudFront distribution. We'll just use a default CloudFront certificate since we aren't connecting this distribution to our domain name in this example. Before we go any further, I would recommend creating a repository for all of your Terraform configs. It will just keep things more organized if you decide that you want to continue to use Terraform for configuring your infrastructure. Anyways... Create a file named main.tf and paste this into. You can change the bucket_name variable to whatever you want, just make sure you set this correctly later on in another file (you'll see as I've highlighted where it needs to be adjusted in the code snippet). {
  default // provider region }

resource bucket acl policy { : , : [
      { : , : , : , : , : }
  ]
}
EOF

  website index_document error_document }
}

locals s3_origin_id }

resource origin domain_name origin_id }

  wait_for_deployment enabled is_ipv6_enabled default_root_object default_cache_behavior allowed_methods cached_methods target_origin_id forwarded_values query_string cookies forward }
    }

    viewer_protocol_policy min_ttl default_ttl max_ttl }


  price_class restrictions geo_restriction restriction_type }
  }

  custom_error_response error_code error_caching_min_ttl response_code response_page_path }

  viewer_certificate cloudfront_default_certificate }
} variable "bucket_name" = "website.example.com" change this} "aws" { = "us-east-1" "aws_s3_bucket" "bucket" { = "${var.bucket_name}" = "private" = <<EOF "Version" "2012-10-17" "Statement" "Sid" "AddPerm" "Effect" "Allow" "Principal" "*" "Action" "s3:GetObject" "Resource" "arn:aws:s3:::${var.bucket_name}/*" { = "index.html" = "index.html" { = "S3-${var.bucket_name}" "aws_cloudfront_distribution" "s3_distribution" { { = "${aws_s3_bucket.bucket.bucket_regional_domain_name}" = "${local.s3_origin_id}" = false = true = true = "index.html" { = [ "DELETE" , "GET" , "HEAD" , "OPTIONS" , "PATCH" , "POST" , "PUT" ] = [ "GET" , "HEAD" ] = "${local.s3_origin_id}" { = false { = "none" = "redirect-to-https" = 0 = 3600 = 86400 = "PriceClass_100" { { = "none" { = 403 = 0 = 200 = "/index.html" { = true Now run the config create the infrastructure: terraform init
terraform - -approve apply auto Awesome! All of our infrastructure is set up in AWS and now we just need to set up our GitLab runner! Configure our Runner For this part, you'll need a GitLab repository for us to work with, so create a new one before proceeding. Now that you have a repository, let's set up our runner. We're going to use a shared runner from GitLab. They're free to use up for up to 2,000 minutes of deployments per month -- and they're enabled by default. I've found that they're somewhat slow and it stinks that you're throttled at 2,000 minutes, so I usually use my own runners spun up in Kubernetes or on EC2 instances, but let's save that for another tutorial. We need to supply the runner with an AWS IAM user to use to deploy to S3. Create another terraform config with this content: {
  description default // provider region }


resource user pgp_key }

resource name user policy { : , : [
        { : , : [ ], : },
        { : , : [ , , , , ], : [ },
        { : , : , : }
    ]
}
EOF
}

resource name }

output value }

output value } variable "keybase_user" = "A keybase username to encrypt the secret key output." = "dannextlinklabs" change this} "aws" { = "us-east-1" "aws_iam_access_key" "gitlab_ci" { = "${aws_iam_user.gitlab_ci.name}" = "keybase:${var.keybase_user}" "aws_iam_user_policy" "gitlab_ci" { = "gitlab-ci-policy" = "${aws_iam_user.gitlab_ci.name}" = <<EOF "Version" "2012-10-17" "Statement" "Effect" "Allow" "Action" "s3:ListBucket" "Resource" "*" "Effect" "Allow" "Action" "s3:PutObject" "s3:PutObjectAcl" "s3:GetObject" "s3:GetObjectAcl" "s3:DeleteObject" "Resource" "arn:aws:s3:::website.example.com/*" // this needs to be set to your bucket name            ] "Effect" "Allow" "Action" "cloudfront:*" "Resource" "*" "aws_iam_user" "gitlab_ci" { = "gitlab-ci" "access_key" { = "${aws_iam_access_key.gitlab_ci.id}" "secret_access_key" { = "${aws_iam_access_key.gitlab_ci.encrypted_secret}" Make sure you set the keybase user to your own keybase user, because Terraform uses that to encrypt the IAM user's secret access key. This won't work if you don't have a Keybase account, or if you try to use my Keybase account. Run the config. terraform init
terraform - -approve apply auto The terraform config returns an access key and an encrypted secret key for this user. We need to decrypt the secret key with the command (this is why you needed to use your own keybase user). terraform output encrypted_secret | --decode | pgp decrypt base64 keybase Now that we have the access key and the secret key for our GitLab user, we just to supply these variables to our runner by adding them to the variables section in the CI/CD settings. We need to set three variables in GitLab: AWS_ACCESS_KEY_ID - the access key that Terraform returned us
AWS_SECRET_ACCESS_KEY - the access key we just decrypted
AWS_DEFAULT_REGION - us-east-1 to to secret Create our super-duper simple website We have an empty repository set up with our GitLab runner enabled, so l Super cool website! Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore
      magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
      consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
      Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. < > html < > body < > h1 </ > h1 < > p </ > p </ > body </ > html Commit that and push it to the repo, and that will be all we need for the "design". Run a Deployment GitLab CI/CD is based around a file called .gitlab-ci.yml. GitLab requires that file to be located in the root of your project. Our file needs to look like this: stages:
  - - variables:
  AWS_BUCKET: website.example.com // change this if necessary
deploy_s3:
  image: python:3.6
  stage: deploy-s3
  tags:
    - - before_script:
    - script:
    - only:
    - deploy_cf:
  image: python:3.6
  stage: deploy-cf
  tags:
    - - before_script:
    - script:
    - - only:
    - deploy-s3 deploy-cf docker gce pip install awscli -q aws s3 sync . / --delete --acl public-read s3: /$AWS_BUCKET/ master docker gce pip install awscli -q export distId=$(aws cloudfront list-distributions --output=text --query ] cut -f1) 'DistributionList.Items[*].[Id, DefaultCacheBehavior.TargetOriginId' | grep "S3-$AWS_BUCKET" | read -r dist; aws cloudfront create-invalidation --distribution-id $dist --paths ; done <<< while do "/*" "$distId" master This gitlab-ci file sets up two stages: deploy-s3, and deploy-cf. The first stage uploads our website to the S3 bucket, and the second invalidates the CloudFront distribution for that bucket in order to present the new changes to our website! This simple configuration is all you need to have a complete CI/CD pipeline for your business' website. Commit and push those changes, and then check out the pipelines section under the CI/CD tab in that project. You should see a deployment running. Success! You have a working CI/CD pipeline. Now, whenever you commit code to the master branch, GitLab will auto-magically upload and distribute your changes! Daniel Slapelis is a Devops Engineer with NextLink Labs, a Pittsburgh-based Devops and full stack engineering company.

Learn How to Build a CI/CD Pipeline Using GitLab for your Website

Well, I just knew the basics and I knew as well that I wanted to learn to code, no matter what, as I explained . here After some time trying to learn it by myself, I figured out that would be better for me to sign up for a coding bootcamp in my hometown. For those who just want to play the game and are not interested on the story on how it was made, ! here it is And oh boy! Coding almost every single day, with LABS (homework) to do, teachers available to reach for whenever I need some help or guidance and a group of other students that are in the same situation as me has really made a difference on my learning pace. But I'm not here to tell you -if you're learning how to code- that you must sign up for one of these, everyone has different oppinions about them. I'm here to explain what I was able to made after the first module, just learning HTML, CSS and Javascript. The final project of the module was a game that we had to develop on 2 weeks. We had complete freedom on how to do it, the one and only rule was not to use any framework. Here, in Spain, when you have to get your driving license, you must pass a medical test. This test is kind of boring, just evaluating how well you see and hear, but it had as well one thing that made it very enjoyable: a little coordination video game. The player is represented by 2 dots (one for each hand) that move only in horizontal. It consists on two little roads viewed from above which sudden turns to the right or left, with the purpose of making it a challenge to maintain both dots in the middle of the road. So, the purpose of the game is to avoid stepping out of the way. The game will finish at a certain point, and then a game-over screen will show the percentage (%) of the time that the player stepped out of the way, from the start to the end. I never played that kind of game before and I've never played it after, but it stuck on my head since then, some years ago. So I decided to re-make it. First of all, I tried to organize all the work that had to be done in a on Github: Readme file The game state will consist on just 3 screens: The --> Title + Start button Start Screen The actual --> Instructions + Play button --> Javascript Canvas Game Screen The --> Result + Play again button Game Over Screen Then the development of the MVP (minimum viable product) for the actual game will be like this: Create a dot and show it on the screen. Move dot horizontally --> Click on right or left arrows to move player on the Canvas. Create the road --> First, a straight line. Then, add turns, right or left. Check collision (when the dot is stepping out of the road). If collision --> Sum time that the dot is out of the way --> Change colors. End game at a certain point (? seconds). Replicate it for both hands. Then I had other kinds of stuff I wanted to add if I had enought time, like: Adding background music and sound effects Make it beautiful with CSS It was actually my first time making a game, my first time using and my first time trying to organize my code in a kind of Model-View-Controller way ( ). Canvas MVC If you don't know, Canvas is represented by a square that allows us to "paint" things on the screen with Javascript and the Model-View-Controller is a concept that helps us in not having all the code in a single huge file, but separating concerns and making it easier to read and maintain. I reached out to the conclusion I had to create these files: A to place the HTML tags and some content. index.html A to put the CSS. stylesheet.css A that will act as the view, getting data from and updating the HTML. main.js A that will act as the controller and model at the same time, having the logic inside. game.js A and that will create those other dynamic and replicable parts needed. player.js path.js For the sake of simplicity, I didn't even host the game in any place, I've just linked to my Github repo to deploy it fast and easy. It's a great tool! Netlify On Github, I started for the first time to use . Having a branch means creating like a "clone" of all your code files, and that allows you to change it and test it without worrying too much about messing up. Once you have something that works, you can "merge" this test branch/es with your main code (usually called the "master"). branches I decided to call my game ' ' in a retro reference and I started to code. Coordinator 2000 Showing a little square on the screen was the easiest part. I placed on the HTML file the canvas tag: < = = = > canvas id "coordinator" width "1200" height "600" </ > canvas On the main.js file, "take" the canvas: canvas = .getElementById( ); let document 'coordinator' Give it a context, so it knows what kind of a drawing board is: ctx = canvas.getContext( ); let '2d' And initializing the class 'Game' with that property: game = Game(ctx); let new Inside the game.js file, a method to draw it: _drawPlayer(player) { .ctx.fillStyle = player.color; .ctx.fillRect(player.x, player.y, player.width, player.height);
  }; this this And so on... I'm not diving into the code itself (you can see it ) because it will take ages to describe what's going on in every line and what happened in every step during those 2 weeks, but I'm commenting the highlights: here I first thought that I should create 2 lines to define the road and then move them in some way, until other student from my class told me that maybe would be easier to just create of the same color, one on top of each other to make the road. an array of little rectangles Then, moving the road to draw the turns would be as easy as adding or subtracting the X position when adding new rectangles on the array. I ran into a little problem, as the array was getting bigger and bigger the browser started to show signs of underperformance, almost freezing at some point, so I just added a function that was deleting the rectangles from the array as soon as those stepped out of the canvas: _deletePath(array) { ( i = ; i < array.length; i++) { (array[ ].y >= .canvasHeight) {
        array.shift();
      } 
    }
  } for let 0 if 0 this Also, I didn't know how to make the turns dynamic, so I just harcoded them: _generateTurnsR() { lastItem = .rightPathArray[ .rightPathArray.length - ]; ( .frames >= && .frames < ) { ._generatePathR(lastItem.x += ); 
  } ( .frames > && .frames < ) { ._generatePathR(lastItem.x -= );
  } ( .frames > && .frames < ) { ._generatePathR(lastItem.x); let this this 1 if this 0 this 160 // turn right this 1 else if this 155 this 220 // turn left this 1 else if this 215 this 420 // straight this Adding a on the 'update method' allowed me to place turns every few seconds, just adding or subtracting the X position of the little rectangles. frames counter During those 2 weeks, there was some days that I was extremely frustrated, as I coudn't figure out how to do things. Luckily, I had Alex, a teacher assistant available, that sometimes helped me pointing to the right direction. At the end, there's still some (if you notice playing the game, when the left dot steps out of the road, the border doesn't become red, as the right one does), some (the timer is a GIF image, instead of code, because I didn't have time left to do it properly) and the code, after being refactored by me a few times, is still sloppy and full of don't-know-how-to's (for example, I did all the CSS as quickly as possible, without taking into account screen sizes or responsiveness). bugs bad practices Still, is the first "thing" created by me coding all the lines, one by one. In the past, I created a few webpages, but all of them where using Wordpress and the sensation is not the same. This is a thousand times more exciting! And now... yes! you can play it ! :) here

I Built a Game in Vanilla JS And I Didn't Know How to Code 3 Months Ago 

Let’s get some state managed 💃 There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton Well, I guess Phil Karlton never had to deal with managing state on the front end..! State management is one of “ ”. Backends roll their eyes, frontends hide under the desk. After all, managing state is the hardest part of being a frontend developer: you need to think in terms of the UI as something that changes over time. And we are not particularly good at it. those things In this post, we will discover how to from the ground up. We will end up creating our own state manager generator! handle state in a Vue application Let’s dive in: Step 1: Our first app. Election Day! First of all, we need an application. We cannot manage an application state without an application, right? Let’s create a voting app, to let you folks vote for the next President(?): Yes, I merged Single File Components and inline components. TODO (REMOVE BEFORE PUBLISHING): avoid making jokes about politics. Not a good time, not a good time. The code above renders something as pretty as this: It looks like the browser failed to load the CSS I can hear your brain screaming: “ ”. Man, you are not managing state. You are just passing props down to each component. You promised state management. You better deliver Well, isn’t passing props the simplest form of “state management”? Isn’t our main component holding both and , our pieces of state? red blue (The answers are YES and YES) But yeah, I hear you. Passing down props is not pretty nor comfortable nor scalable, so let’s try something else. Step 2: Isolating state Let’s create a “state holder” object and manage our whole state from there. const = {red: 0,blue: 0,} state There it is! Our application state, properly held and encapsulated. It wasn’t that hard! Now, from our components, we could do something like the following: const = {render: h => h('div', `Total votes: ${state.red + state.blue}`)} TotalVotes const = {render: h => h('div', `Red: ${state.red} - Blue: ${state.blue}`),} Results // ...and, inside our main component,...methods: {voteForRed () { state.red++ },voteForBlue () { state.blue++ },}, Spoiler: . Why? this is not going to work Because Vue uses method to trigger its “magic reactivity”. Without passing our data to (heh), Vue won’t be able to track down value changes and update our components in response. data data Easily said, fixed: easily(?) A few things happened there: Look ma’, no props! (lines 8, 9) Every component registers our state in their method. Now Vue is able to track down state changes, so when we vote for 🔴 all our components with the proper value. data rerender (lines 20, 27, 35) We had to remove our pretty arrow function from the render functions because now we are using . this (lines 21, 28) Now our state it “isolated” from components. . Free as in beer (line 14) Ok, so now we have our state separated from our “UI implementation”, but that came with some caveats: in , we cannot use the beautiful arrow functions in our render functions… we need to register our state to each component data() But. Wait. Did I just say “ ”. Vue needs to register data in _data()_ to make it reactive? Yes, I did. But in my solution I’m using every component instance to make the very same data reactive, right? Yes. And could I create a shared Vue instance to hold that reactivity, so my components don’t have to? Well, yes. Let me write a big heading: Step 3: Create a shared Vue instance to hold that reactivity So, information stored in becomes “reactive by default”. And what is the piece of information we want to make reactive? data() Our state! So what if we did this? const state = new Vue({data () {return {red: 0,blue: 0,}},}) Neat! Now our state is reactive. We’ll be sharing a Vue instance for all the data, but that’ll be waaaay cleaner than my previous solution, right? But, wait. Wait. Wait. We have a Vue instance, now. And do you know what a Vue instance can hold, besides reactive data? Exactly: . methods Now our and methods can be with our state! voteforRed() voteForBlue() collocated Let’s check it out: Vuetiful! Let me highlight the improvements we achieved: State and methods that mutate our state are now . No more leaking implementation details! Notice that our voteFor methods are quite simple, but that they could be as complicated as needed. placed together (lines 9, 10) We still need to call these methods from our component. (lines 25, 26) Back to our render functions with arrows. (lines 15, 19) And we removed a lot of boilerplate code (all the declarations). data() Okay, so far so good! Our current solution is terse, simple, and idiomatic. But we need to import Vue, and then create a new instance. While this is not inherently “bad”, I feel we could do better, couldn’t we? For instance, our solution cannot be shared among projects right now. I need to teach people to create a Vue instance, populate its method, then register some methods to modify the state… way too much. data It’s time to… Step 4: Encapsulate our state in a function Fortunately, Javascript provides us with a cool feature that allows us to hide all those details and keep things simple: functions. We are gonna create our . factory function Let’s define our function. What’s the API? I would expect: createStore A parameter to set our initial state. We could call the parameter “state”, for the sake of clarity. data A list of mutations functions to change my state when needed. We could call the parameter “mutations”, for the sake of clarity. Finally, I would expect our to expose a generic method that would allow my components to “run” the mutations. We could call the parameter “commit”, for the sake of clarity (you usually , right?). createStore commit mutations You see where I’m going, don’t ya. We want to end up writing this: const store = createStore({ : { red: 0, blue: 0 }, : {voteForRed (state) { state.red++ },voteForBlue (state) { state.blue++ },},}) state mutations Quite nice, right? And pretty straightforward. Now, how would we implement this helper? Remember that we should use a Vue instance to leverage its reactivity: createStore const = ({ state, mutations }) =>new Vue({data () {return { state }},methods: {commit (mutationName) {mutations[mutationName](this.state)},},}) createStore Some things happened there: First of all, we return a new Vue instance. So far so good. Then, we register our state parameter to the method of the instance. Bam! Our state is now reactive. data() Finally, we create our public method. This method takes a name of a mutation as the parameter, and then runs the very same mutation (and passes our state). If we call , our method will call .Notice that in a real implementation we should handle non-existent mutations! commit() commit('someMutation') mutations.someMutation(this.state) So, how do our component look like, now? const TotalVotes = {render: h => h('div', `Total votes: ${store.state.red + store.state.blue}`),} const Results = {render: h => h('div', `Red: ${store.state.red} - Blue: ${store.state.blue}`),} export default {components: { TotalVotes, Results },methods: {voteForRed () { store.commit('voteForRed') },voteForBlue () { store.commit('voteForBlue') },},} Now we access to get our state, and to modify it (notice that we pass the desired mutation name as parameter). store.state store.commit All together now!: Isn’t that cool? Now we can generate hundreds of thousands of stores by providing a simple method. You’d want to place your in a file and export it, so you can import it in your applications and create a whole new store. Bonus points if you call this file 😁. createStore createStore Vuex.js ✅ That’s a wrap! , … does it sound familiar to you? Well, if you have ever used , it definitely should. We effectively mapped the Vuex API in our example. state mutations Vuex We are missing getters and actions, but I hope you get the idea that Vuex is . It’s a great abstraction, well-polished, useful, scalable. But an abstraction, after all. We just keep adding layers to the heart of the framework: . That’s the core feature that triggers everything. an abstraction of things we already knew reactivity Vuex is . an abstraction of things we already knew A quick recap: State management on the front end is something . My personal recommendation: start as small as possible, and think about it twice before adding new things. Vuex is amazing (it truly is!), but do you really need it yet? scalable is the king of Vue. Everything, and I mean everything, depends on data being reactive. And this is great because we can leverage that reactivity and create nice, useful abstractions. Reactivity Now we understand what Vuex is doing under the hood, which is cool. kinda Sometimes, if it provides context, intent, and repeatability to our code (for instance, step 4 required way more code that step 2). verbosity trumps succinctness Wanna dig in? with 4 commits: one commit per step of the post. Feel free to play with it and inspect every change. I created a Github repo Do you want to practice a bit with our solution? Here’s a challenge: How would you implement ? And ? and… ? 😏 getters actions modules Hope it helps!

Stories, News & Mentions about ADDINGWELL

Addingwell’s Stories on HackerNoon