Apple has a unique opportunity with iOS 18 to take AI features to the masses in a way that hasn‘t happened quite yet.

Apple’s WWDC opportunity: how iOS 18 can make AI mainstream - 9to5Mac

Nvidia&#x27;s shares rallied around 6% to hit a record high on Tuesday, leaving the AI chipmaker&#x27;s stock market value about $100 billion away from overtaking Apple in a major reshuffle of Wall street&#x27;s biggest players.

AI darling Nvidia's market value surges closer to Apple | Reuters

As we prepare for the 2024 Worldwide Developers Conference, Apple today announced its finalists for the Apple Design Awards. Apple chooses the best...

Apple Design Award Finalists Announced Ahead of WWDC 2024 - MacRumors

The new M2 iPad Air is on sale already, and some models are available for record-low prices.

Apple's new M2 iPad Air tablets drop to record-low prices

The Investing Club holds its &quot;Morning Meeting&quot; every weekday at 10:20 a.m. ET.

Apple's iPhone shipments to China surged in April. Jim Cramer says there's more to the story

Imagine asking Apple’s Siri to show you an old photo taken from a child’s second birthday, or summarizing lengthy emails and writing drafts. Then consider Siri learning your schedule, preferences, even your personality, so it can better communicate with you throughout the day.

Here’s how new AI tech could change the iPhone | CNN Business

In April, Apple&#x27;s (AAPL) iPhone sales increased in China as the region saw a 52% boost in shipments of foreign-brand smartphones, according to the China Academy of Information and Communications Technology (CAICT). The turnaround comes after Apple saw double-digit sales declines in the region.

Apple's iPhone sales rebound in China: Can momentum stay up?

Barron&#x27;s is a leading source of financial news, providing in-depth analysis and commentary on stocks, investments and how markets are moving across the world.

Apple Stock Jumps as China Business Booms and Other Tech News Today

Apple&#x27;s (AAPL) iPhone shipments to China shot up by 52% in April, according to the China Academy of Information and Communications Technology (CAICT), after battling slowing demand in the region in the early months of 2024. The Morning Brief team examines this report and whether Apple&#x27;s regional ...

Apple's iPhone sales in China shot up by 52% in April

A new deal has dropped the 10th-gen Apple iPad down to $300, which is the lowest price we&#x27;ve seen for the entry-level tablet.

Apple's 10th-gen iPad falls to an all-time low of $300

Apptile

apptile

In my , I have shown a way to unify the implementation of the most well-known graph-traversal algorithms. Now, let's make it more visually appealing and look into the performance differences. last post The story behind A few years ago, Yandex organized a contest called with an enticing prize: a ticket to a . The contest resembled a game, with participants tasked with finding optimal routes on a map and optimizing delivery using robotic couriers. Robots Couriers closed self-driving conference for professionals As I delved into the topic, I discovered that despite route finding being a solved problem, it continued to interest the professional game development community. Between 2010 and 2020, engineers , particularly beneficial for AAA games with massive maps. Reading on these optimizations was an exciting experience. made significant optimizations to the A* algorithm articles and research papers Furthermore, the contest requirements were designed to enable easy assessment of program outputs by the contest’s testing system. As a result, there was little emphasis on visualization. I found exploring this field intriguing and developing a small application that uses well-known graph algorithms to find routes on a grid map. To visualize my findings, I employed the SFML graphics library. Goal This project builds upon one of , where I demonstrated that four well-known path-finding algorithms (BFS, DFS, Dijkstra's, and A*) are not fundamentally different and can be implemented in a universal way. However, it was challenging to showcase significant performance differences among these algorithms in that project. my previous endeavors In this article, I aim to use improved test data and design something visually exciting. While the Yandex Contest task mentioned earlier aligns well with my goals, I will not solve their specific problem here since it heavily relies on their test system, which is currently unavailable. Instead, I will extract general ideas for input parameters from that contest and create my own implementation. Imaginary world Imagine a technically advanced and innovative city where the future has arrived long ago. In this city, the majority of orders are delivered by courier robots, and it has become a rarity for a person to deliver an order from a cafe. In this task, we invite you to participate in finding optimal routes to deliver orders efficiently. Let's envision the city as an N × N map. For simplicity, we assume that each robot occupies exactly one cell, and each cell can either be passable or not for the robots. In one step, a robot can move in any of the four cardinal directions (up, down, left, or right) if the target cell is free. And I'm of the original task: ignoring the rest At the beginning of the test, you need to output the number of robots you want to use to deliver orders and their initial coordinates. The construction of each robot will cost Costc rubles. Next, T iterations of the simulation will be performed. One iteration represents one virtual minute and consists of 60 seconds. At each iteration, your program will be given the number of new orders, and in response, the program should tell you what actions each robot performs (60 actions per robot). For each successfully delivered order, you will receive max(0, MaxTips - DeliveryTime) dollars in tips, where MaxTips is the maximum number of tips for one order, and DeliveryTime is the time from the moment the order appeared to its delivery in seconds. The total number of points that you earn in one test is calculated by the formula TotalTips - R × Costc, where TotalTips is the total number of tips earned, R is the number of robots used, Costc is the cost of building one robot. The Costc and MaxTips values are set in each test. If you earned less tips than you spent on making robots, your total points will be 0. You will also receive 0 points for the test if you perform any incorrect action. Input The program uses standard input to read the parameters. This approach allows us to specify test data of various complexities using input files. The first line of input contains three natural numbers: N (the size of the city map), MaxTips (the maximum number of tips per order), and Costc (the cost of building one robot). I ignored both MaxTips and Costc parameters for my first implementation and maybe will consider that in the future. Following that, each of the next N lines contains N characters representing the city map. Each string can consist of two types of characters: '#' - indicates a cell occupied by an obstacle. '.' - indicates a free space. Next, you will be provided with two natural numbers: T and D (T ≤ 100,000, D ≤ 10,000,000). T represents the number of interaction iterations, and D represents the total number of orders. Output Your task is to visualize the map and the optimal routes using the SFML graphics library. Modelling the maps I'm fond of maps represented as a grid of cells. Thus, I prefer to render all the results and map them as a grid on cell by cell basis. There is also the option to execute path search right on the grid without using any additional data structure (and I have implemented this as well for learning purposes: see in code). But because of a grid, it is easy to represent a map as a graph in one way or another. I prefer to use an adjacency list of cells for most of the algorithms like BFS, Dijkstra's, and A-Star. For algorithms like Bellman-Ford, it may make sense to use an Edges List instead of an Adjacency List. That's why if you explore the codebase, then you will find all of it, and they all are working examples. To split the logic and responsibility, I have a entity that is responsible for executing path finding according to the orders and tasks configuration that is specified via the file and related map files. Navigator App Config looks like this: App Config {
    "font": "../../data/arial.ttf",
    "map": "../../data/maps/test_29_yandex_weighten_real_map",
    "shadow": false,
    "map_": "../../data/maps/test_08_low_res_simple_map",
    "map__": "../../data/maps/test_10",
    "map___": "../../data/maps/test_07_partially_blocked_map",
    ... Note that "map_” "map__" etc. are not really configuration properties. They are ignored during the application run. Since there is no way to comment on the part of the JSON file, I use underlining in the property name so it can stay in the config file but not be used. looks like this: The map file 25 50 150
#########################
#########################
#########################
###.......#####.......###
###.......#####.......###
###.......#####.......###
###...................###
###.......#####.......###
###.......#####.......###
###...................###
######.###########.######
######.###########.######
######.###########.######
###.......#####.......###
###.......#####.......###
###.......#####.......###
###.......#####.......###
###.......#####.......###
###.......#####.......###
###.......#####.......###
######.###########.######
#########################
#########################
#########################
#########################
2 4
2
6 6 4 20 This is one of the simplest examples that contain either blocked or not blocked cells. I have prepared a lot of various examples of input parameters and test data. Starting from very small parts that let you debug and learn the code, finishing with a huge piece of map (from the real existing city) that allows us to measure the performance of a Graph algorithm. How do we draw such maps? When a map contains only cells with binary state (either blocked or non-blocked), this basically means that any edge of a graph either exists or not. To find a path in the graph, we have to represent it efficiently. Like in my previous post, I have used an with the relationship as Vector[NodeId]->points to->Vector[Neighbour Nodes]: adjacency list typedef std::vector<std::vector<std::shared_ptr<Cell>>> Graph; When we exploring grids it's not really necessary to use graphs at all. We are capable to traverse grid using BFS/DFS algorithms cell by cell without thinking about edges. See method for example. _GetPathByBFSOnGrid First, the initialization code reads the file and converts it into row by row and column by column: the grid bool RectangularMap::LoadMap(const std::string& filepath, bool shadow)
{
...
  // Fill the grid.
  _verticesNumber = 0;
  for (int row = 0; row < _height; row++)
  {
    ...
    for (int col = 0; col < _width; col++)
    {
      int x = col;
      int y = row;
      if (line[col] == BLOCK_CELL)
      {
        // Create a shared pointer here to safely pass pointers between the classes.
        _grid[row][col] = std::make_shared<Cell>(x, y, line[col], blockColor, shadow, _scaleFactor);
      }
      else
      {
        ...
      }
    }
  }

  // Make a graph
  InitialiseGraph();
...
} Then, it creates an actual graph as : an adjacency list void RectangularMap::InitialiseGraph()
{
  MapBase::InitialiseGraph();
  ...
  unordered_set<int> visited;

  for (int rr = 0; rr < _grid.size(); rr++)
  {
    for (int cc = 0; cc < _grid[rr].size(); cc++)
    {
      if (_grid[rr][cc]->GetId() > -1)
      {
        for (int i = 0; i < 4; i++)
        {
          int r = rr + dr[i];
          int c = cc + dc[i];

          if (r >= 0 && c >= 0 && r < _width && c < _height &&
              _grid[r][c]->GetId() > -1)
          {
            if (_isNegativeWeighten)
            {
              ...
            }
            else
            {
              _adjacencyList[_grid[rr][cc]->GetId()].push_back(_grid[r][c]);
            }
          }
        }
      }
    }
  }
} Grid representation is useful to draw on the screen using the SFML library. We can draw (this is exactly what I do for small maps): by creating a geometric object ...
for (int j = _visibleTopLeftY; j < _visibleBottomRightY; j++)
{
  for (int i = _visibleTopLeftX; i < _visibleBottomRightX; i++)
  {
    _grid[j][i]->Draw(_window, _scaleFactor);
  }
}
...
sf::RectangleShape tile;
tile.setSize(sf::Vector2f(_cellSize - 5, _cellSize - 5));
tile.setPosition(sf::Vector2f(_x * _cellSize, _y * _cellSize));
tile.setFillColor(_color);
window.draw(tile); Or we can do it for larger maps: efficiently pixel by pixel sf::Uint8* pixels = new sf::Uint8[_width * _height * 4];

for (int j = _visibleTopLeftY; j < _visibleBottomRightY; j++)
{
  for (int i = _visibleTopLeftX; i < _visibleBottomRightX; i++)
  {
    int index = (_grid[j][i]->GetY() * _width + _grid[j][i]->GetX());

    sf::Color color = _grid[j][i]->GetColor();
    pixels[index * 4] = color.r;
    pixels[index * 4 + 1] = color.g;
    pixels[index * 4 + 2] = color.b;
    pixels[index * 4 + 3] = color.a;
  }
}

sf::Texture texture;
texture.create(_width, _height);
texture.update(pixels);
sf::Sprite sprite;
sprite.setTexture(texture);
sprite.setScale(cellSize, cellSize);
_window.draw(sprite); Finally, let's see what a map defined by file would look like. Originally, the file defined this: test_25_xmax ..............C.................
..............#.................
.............###................
............#####...............
...........#######..............
..........##1###2##.............
.........###########............
........##3######4###...........
.......###############..........
......#################.........
.....###################........
....#####################.......
.............###................
.............###................
.............###................ And a map renderred with SFML looks like this: Because I wanted all of that to be controlled by the user with the keyboard, I left all the user-behavior logic in the . I like to call it “Controller” logic. main.cpp SFML library makes it very easy to handle keyboard events: while (window.isOpen())
{
  Event event;
  while (window.pollEvent(event))
  {
    if (event.type == Event::Closed)
      window.close();

    if (event.type == Event::KeyPressed && event.key.code == Keyboard::Space)
    {
      ... Do what you need here
    }
  }
} The main idea is for user triggers (press of a SPACE button) to read the map file and rendering the map, and then by a second trigger (second press of a SPACE button) to load the routing task and calculate the shortest path between two points on the map: ...
if (navigator->IsReady())
{
  navigator->Navigate(); // Finding route between two points
}
else
{
  if (map->IsReady()) // Second SPACE press runs the routing
  {
    skipReRendering = true;
    if (navigator->LoadTasks(filepath))
    {
      navigator->SetMap(map);
    }
  }
  else // Load and draw map
  {
    drawLoading(window, font);
    if (!map->LoadMap(filepath, shadowed))
    {
      return 0;
    }
    drawProcessing(window, font);
  }
}
... We need to go deeper I wanted to play with more Graph algorithms, and they all have their limitations, so I decided to implement multi-color maps that can be represented by multi-weighted graphs. Every cell is colored, and the color means that the edge not only exists but also applies some weight (or fee, or fine, you name it). So, the edge might be blocked, half blocked, not blocked, ... you got the idea. Thus, I have implemented multi-color maps that look more joyful and look like a game-ready (example from file ): test_31_multi_weight_graph_map Some of the configuration files contain more complex maps from really existing cities, like : test_29_yandex_weighten_real_map As a challenge, now we should handle maps with very flexible configuration. essentially contains a lot of logic inside, including all the graph algorithms and even more than needed (because I like to play with things, even if it's not particularly useful for now). RectangularMap.cpp I have implemented , , , algorithms, and a number of additional "utility" algorithms like Topological Sort, Single Source Path, that are not useful for the current application state (because they work on Directly Acyclic Graphs, which are not type of Graphs I currently use), but I have some ideas to use it in future improvements. BFS#Line 598 Dijkstra#Line 299 A-Star#Line 356 Bellman-Ford#Line 428 I didn't polish all the code and didn't get it ideal enough, but it allows me (and, I hope, will allow you) to play with the code and compare performance metrics. Sorry about some commented lines here and there, maybe some dirty code...it's all way of learning :). To grasp an idea of what's inside, I recommend you review the . RectangularMap.h There are also some fun features, like a Focus feature that allows one to render only a particular part of a map. It changes focus by re-rendering the necessary part using the when the user presses the PgDown or PgUp buttons. It is pretty easy to improve this feature and implement "Zoom" functionality. Take it as a homework, if you like it. Observer pattern Focus feature with map file in work: test_29_yandex_weighten_real_map Classes diagram looks like this: Run and play I believe the most joyful part is just running this little application is playing with variations of its configuration and algorithms. You can do a lot of experiments by using various map files as input parameters with different test data as well as change the logic in the code. After starting, you need to press SPACE an application will render a map according to the configuration file, and it makes a lot of sense to start exploring from the simplest test cases and moving forward to the most complex ones. Pressing SPACE one more time executes the routing algorithms and finds the path between the start and the nearest order. BTW, It's not yet done, but it is easy to implement reading all the rest of the orders available in map configuration files and execute pathfinding to all of them. Here is the route found on the map defined by file : test_18_yandex_super_high_res It is also capable of finding routes in the maps that simulate existing cities, like : test_29_yandex_weighten_real_map Finding efficient paths between two coordinates becomes challenging for algorithms like BFS but can be easily done by A-star. Based on the cells found in the map configuration files, the application will treat the map as a weighted or non-weighted graph and will select the right algorithm for it (and you can easily change this as well). It's easy to see the difference between BFS and A-Star performance: Final words With this, I want to leave you alone and let you play with these code examples. I hope you will find it fascinating and will learn a lot from it. Stay tuned! Links JPS+: Over 100x Faster than A* by Steve Rabin A* Optimizations and Improvements by Lucho Suaya https://hackernoon.com/bfs-dfs-dijkstra-and-a-star-are-basically-the-same-algorithm-ill-show-you-why My blog https://antonyarkov.substack.com/ Also published . here

Graph Traversal Algorithms: Visualizing Performance Variations in Route Finding Algorithms

GraphQL is an API technology that is rapidly gaining popularity among thousands of enterprises around the world. It was built to improve many aspects of REST, one of them being that GraphQL provides a native way to expose an API schema. This schema makes it easier than ever to generate API documentation with little effort. Introducing Magidoc Magidoc is an open source tool that can be used to easily autogenerate static GraphQL documentation for any GraphQL API, either from SDL files or from a live endpoint using the introspection query. Not only can you use Magidoc to generate beautiful and easy to understand API documentation out of the box, but you can also provide custom pages using markdown. These pages allow you to present your API however you want. For instance, you could describe different concepts, examples, flows, URLs, etc. Getting started Schema (SDL) First, we need a schema. For the sake of this demonstration, let’s use a simple TODO application schema. In a file named , we will put the following code. schema.graphqls type Todo {
  id: ID
  name: String
  complete: Boolean
}

input TodoInput {
  todoId: ID
  name: String
  complete: Boolean
}

type Query {
  """
  Returns all TODOs 
  """
  todos: [Todo]
  """
  Return a specific TODO by ID. 
  """
  todo(todoId: ID): Todo
}

type Mutation {
  """
  Creates a TODO and returns it.
  """
  createTodo(input: TodoInput!): Todo
  """
  Updates a TODO or returns an error if it does not exist.
  """
  updateTodo(input: TodoInput!): Todo
  """
  Toggles a TODO or returns an error if it does not exist.
  """
  toggleTodo(todoId: ID!): Todo
  """
  Deleted a TODO or returns an error if it does not exist.
  """
  deleteTodo(input: TodoInput!): [Todo]
} Magidoc configuration Then, we need a Magidoc configuration file. Magidoc uses configuration as code, which means that the configuration is nothing more than a Javascript file. This allows you to implement logic in it. For our example, let’s write the following configuration in a file called : magidoc.mjs export default {
  introspection: {
    type: 'sdl',
    paths: ['./schema.graphqls'],
  },
  website: {
    template: 'carbon-multi-page',
    options: {
      appTitle: 'Medium Article',
      appLogo: 'https://seeklogo.com/images/P/Pokemon-logo-497D61B223-seeklogo.com.png',
      pages: [{
        title: 'Medium Article',
        content: `
# Medium Article
Congratulations! You've successfully completed the Magidoc tutorial.
## Where to go next?
- Star the project on [GitHub](https://github.com/magidoc-org/magidoc) 
- Read the [documentation](https://magidoc.js.org/introduction/welcome)
`
      }],
    },
  },
} In this example, we load our schema from an SDL file. We also configure different website options, like the , and a custom page that contains markdown that will be rendered by Magidoc in the output website. appTitle appLogo Magidoc supports advanced markdown features like tables, ordered and unordered lists, inline HTML and much more. Build it Finally, to build our website, we’ll execute the following commands: npm install --global @magidoc/cli@latest
magidoc generate
magidoc preview These commands will install Magidoc, generate the website and then preview the output locally. And there you have it! A static GraphQL API documentation. Conclusion Magidoc is a powerful tool that can help you build superior GraphQL documentation very easily. This tutorial only scratches the surface of all that is possible to do with Magidoc. Many more advanced features exist, like a development server with hot-reload, the ability to provide custom assets (images or videos), full customization of the template using Svelte & Svelte-Kit, and many more built-in customization. Make sure to check out the documentation to learn how you can turn your GraphQL schema into branded documentation website for your company, and have a look at the if you’re interested in contributing. Github repository Thank you for reading!

Autogenerate Your GraphQL Documentation With Magidoc

Creating and Releasing an App with Flutter: Part II

Introduction There are quite a few myths related to Single Page Application (SPA) and SEO, for example: SPA is bad for SEO. Use SPA if SEO is not important. Indexing requires prerendering which leaves SPA out in the cold. Indexing requires server-side rendering (SSR) which excludes client-side rendering (CSR) and therefore SPA that does CSR. Google generally understands SPA but crawling/rendering/indexing is a complex process. It makes indexing of any SPA difficult. Today’s reality is that both SPA and SEO can easily coexist and grow next to each other. The best way to dispel the surrounding myths is to present the evidence to the contrary: SPA Website Note Declared Sitemap Proof of Indexing crisp-react.winwiz1.com Demo website. Full-stack deployment. sitemap.xml Link Screenshot jamstack.winwiz1.com Demo website. Jamstack deployment. sitemap.xml Link Screenshot virusquery.com Production website. sitemap.xml Link Screenshot The Links in the table point to Google searches based on the keyword. Only indexed pages can appear in the search results, so if a page does show up then you know it has been indexed. However, not all indexed pages are guaranteed to be included. If a page doesn’t appear, you can perform a more specific search for the given page only, like . site: site: this The Screenshots shown in the table come from (GSC). It’s the primary tool to request and verify indexing. Google Search Console Some screenshots show the indexed pages as . It’s confusing since the pages are actually included in . This wording means Googlebot has initially discovered the pages without the sitemap and keeps crawling these without regards to the available . “Indexed, not submitted in sitemap” sitemap.xml sitemap.xml The rest of this article explains the steps aimed at getting a similar GSC screen for your SPA website. Groundwork Prerequisites Custom domain ownership. GitHub account. Cloudflare account. It's free and can be created by following this . link Installed software: Git. Deploy a SPA In this section we are going to deploy a React SPA to Cloudflare Pages using the following steps: Open a command prompt and clone Crisp React repository: git clone https://github.com/winwiz1/crisp-react.git cd crisp-react Create a new GitHub repository by visiting . repo.new Point the cloned repository to the newly created one and push it there: git remote set-url origin https://github.com/your-github-username/your-newly-created-repo git push Deploy to Cloudflare Pages by logging into the and creating a Cloudflare Pages project. Cloudflare dashboard This step will take several minutes spent mostly on waiting. It should take around a minute to copy the data provided below and paste it into the single configuration screen presented by Pages. Use . You will be asked to authorize read-only access to your GitHub repositories with an option to narrow the access to specific repositories. Select the repository which you pushed to GitHub at the previous step and on the "Set up builds and deployments" screen, provide the following information: Menu > Pages > Create a project Configuration option Value Production branch master Build command yarn build:jamstack Build output directory client/dist Add the following environment variable: Environment variable Value NODE_VERSION 16.13.1 Optionally, you can customize the "Project name" field. It defaults to the GitHub repository name and is used to create a 'per-project subdomain' e.g. . <project-name>.pages.dev After completing the configuration, click on the "Save and Deploy" button. When the deployment pipeline finishes, the website will be partially functional. Point a browser to to check the site is online. https://<project-name>.pages.dev/first Let Cloudflare manage DNS for the domain you own and want to use for the deployment. You don’t have to change your domain registrar to Cloudflare though you could if you want to. If you do or if you purchase a brand new domain through Cloudflare, skip this step. Use the top-level menu available in the Cloudflare dashboard. In response, Cloudflare will provide you with the names of two DNS nameservers. Login to the domain registrar account and change the nameservers from the ones supplied by the registrar to the nameservers provided by Cloudflare. Add a site In the Cloudflare dashboard, use the DNS menu to add a record: Type Name IPv6 Address AAAA subdomain 100:: Replace with either a subdomain name e.g. to deploy to or apex e.g. if you prefer to use the root domain.  Check the "Proxy status" of the record is set to "Proxied". subdomain jamstack jamstack.<your-domain>.com @ The "Proxied" status ensures the DNS record won't become public. Cloudflare will create another public DNS record that ensures the requests for are routed to Cloudflare datacenters. Once handled there, the requests would have been dropped since the address is used to discard traffic. But in reality, the requests will be handled by the Worker we are about to create at the next step. subdomain 100:: Create a Cloudflare Worker by visiting and replace the auto-generated code with the content of file. Modify the Worker Customisation block at the top of the code by following the suggestions in the comments. Modifying the code includes two steps: workers.new this Edit the variable and replace all the occurrences with . siteMap jamstack.winwiz1.com <subdomain>.<your-domain>.com Edit the variable and replace the single occurrence of with the per-project subdomain e.g. . pagesDomain https://crisp-react.pages.dev https://<project-name>.pages.dev Click on the “Save and Deploy” button. This step along with the next one will be automated in the future. The default Workers Plan is free but has a limitation: 100,000 invocations per day. Unmap the Worker from the domain it was automatically deployed to. Map it to your custom domain or subdomain instead to ensure the Worker is invoked to handle each request. For example, the Worker for should be mapped to the path . *.workers.dev <subdomain>.<your-domain>.com <subdomain>.<your-domain>.com/* Point a browser to and verify the website is online and functional. https://<subdomain>.<your-domain>.com Request Indexing In this section, we’ll ask Google to: Confirm that each SPA page can be indexed, Accept a request to index each SPA page. Both confirmation and acceptance will be obtained by using which is a part of GSC. Google URL Inspection Tool Perform the following steps: Add some original content to the deployed website in order to avoid . duplicate content In the SPA , set the variable to a different title. Review the SPA codebase to ensure each page correctly sets the HTML element and the canonical tag to the values meaningful for the page. This can be done by searching all files for the pattern and reviewing the relevant code. Configuration block appTitle <title> <meta> .tsx <Helmet> If you have changed not only the content of a webpage but also its path or added new pages, then you will need to modify the Worker Customisation block to reflect the changes. Commit the code changes made at the previous two steps and push the commit to your GitHub repository. The push will trigger an automated build and deployment of the website by Cloudflare Pages. the domain you own to GSC using the “+ Add Property” menu. Add For example, the production was added as a domain property whereas for the demo websites the root domain was added first as a domain property . Once Google has verified the domain ownership, both demo websites were added separately as a URL property each e.g. and . website virusquery.com winwiz1.com https://crisp-react.winwiz1.com/ https://jamstack.winwiz1.com/ Click on the “URL Inspection” menu to activate the and type the path to the page you would like to index: URL Inspection Tool You can copy the path from and paste it. On contrary to the screenshot above the response will state that “URL is not on Google” telling you the page hasn’t been indexed yet. sitemap.xml Click on the button to get a confirmation the page can be indexed. Optionally review the screenshot of the page rendered by GSC. "TEST LIVE URL" Request indexing for the page by clicking on the link. The response should say your request has been added to the priority crawl queue. "REQUEST INDEXING" The last 3 steps will have to be repeated for all the pages of each SPA. Follow-up You can use the “URL Inspection” menu to monitor if the page was indexed. It can take from a few days to a couple of weeks for the page to be added to Google index. At which time the response will state: “URL is on Google”. When that happens, you can double-check that the page was indexed by performing Google search using the keyword. site: Finally, it will take up to another week for the indexed pages to appear in the indexing report under the GSC “Coverage” menu. Under the Hood Let’s dissect what the Cloudflare Worker does and find out when & why is it needed. Plain SPA Google has no trouble with rendering a SPA presented by a typical HTML file that has a nearly empty element with references to scripts only. This HTML markup makes sense for CSR since the HTML and the DOM are generated at run time in the browser’s memory. You can observe such a markup on the demo websites mentioned at the beginning of the article, just jump to the second SPA and right-click on the page to ‘View page source’. <body> The page that belongs to the second SPA is indexed. It suggests the concern about the alleged fundamental troubles that Google has with an ‘empty’ SPA page has no merit. The only difference is the extra ‘Rendering’ stage in the indexing pipeline. Also when you click on the link in GSC to inspect that particular page, the screenshot of the page appears on the right pane. It proves the scripts were duly run resulting in proper rendering of the ‘empty’ page. "TEST LIVE URL" Selectively Prerendered SPA Now let’s switch from a plain SPA to the one with the landing page prerendered. Crisp React builds such SPA to combine landing page prerendering with CSR for other pages. This is done to achieve performance. Once the landing page is prerendered, the SEO troubles start. The indexing pipeline sees the HTML markup generated by prerendering and decides that it can optimise the scripts out. It assumes there is no need to run any client-side scripts because the markup, and therefore the page content, is already there. No client scripts execution amounts to having no CSR and no SPA page switching. As a result, GSC reports under the “Coverage” menu that all the non-landing pages are treated as duplicates of the landing page and not indexed. Despite of all the pages having different content. The remedy was simple. After in Cloudflare Worker was used to strip out the prerendered HTML markup, all internal (e.g. non-landing) SPA pages were indexed. HTMLRewriter An attentive reader can ask if this amounts to website cloaking. The answer is No. Google provides definitions for ‘hybrid rendering’ and ‘dynamic rendering’. Both result in Googlebot and users receiving different content which effectively is a cloaking, albeit permitted by Google. In our case the rendering stage of Google indexing pipeline sees what is rendered by the script whereas users are presented with the output of React function which yields the same HTML markup and page content. renderToString Cloudflare Worker Functionality The Worker is used to implement the following features: Feature: Conditionally remove prerendering for bots but not for end-users. In Crisp React the prerendering is optional so if no SPA has it enabled then obviously no need to remove it. Alternative: If you need prerendering but are not using edge functions like Workers, then switch from Jamstack to full-stack deployment and implement prerendering removal in the backend e.g. Express. The implementation is as simple as finding the element and removing its children. div.app-root Feature: Implement SPA redirects. This is done as a workaround for Cloudflare Pages assumption that any SPA has the landing/index  page called . This is not necessarily true for Crisp React, it allows a React application to be split into multiple SPAs and you can name each as you like. index.html Alternative: Use one SPA only and rename it from ‘first’ to ‘index’ to let Pages perform redirects. Or switch to full-stack deployment and implement redirects in the backend. Feature: Generate auxiliary files e.g. , . sitemap.xml robots.txt The files are created on the fly and are not persisted to the disk. Alternative: The files could be created on the disk during build time or generated on the fly by the backend in full-stack deployments. Conclusion Hopefully, this article sheds some light on the SPA & SEO topic. As you could see, the overall picture is quite bright and certainly not as bleak as frequently painted. Getting your website indexed is only the first, though critical, stretch of the long SEO road. It’s highly recommended to ensure your SPA includes meaningful Structured Data. Crisp React with that by providing static and dynamic placeholders you can replace with data that contributes to the SEO of your website. assists Thank you for reading!

Single Page Application: Dispelling  SEO Myths

I created a tool for , called code-workshop-kit. It makes remote workshops interactive and allows for experiences similar to those in a classroom, and better. people that teach code In this blog I will explain the problems of code workshops, why I created and how you can use it. remote code-workshop-kit In today’s world, more and more workshops and trainings are held online rather than offline. Instead of standing in front of a classroom in a real physical location, we often find ourselves educating in front of a digital Teams or Zoom room. This transition has been happening for many years, gradually. Then, COVID-19 hit us, meaning that more and more people are now permanently working from home and classrooms with a bunch of people in a small room are a no-go in most places. Even though I am optimistic about the future of this pandemic, it still seems likely that it has sped up this transition of workshops and education. I foresee that even most conferences will embrace digital means of attending from now on, which would include their workshops being held remotely as well. Challenges in online workshops Next to my daily work as a web developer, I am also an educator, giving workshops and full-day training usually twice a month or so. My style is very , and . This requires input from my participants. If you happen to be like me in this regard, you will recognize the following problems when giving such training online. interactive hands-on, exercise-driven . When you ask a question to the room of online participants, you will likely find that it’s much less common for people to answer. Part of this is a lack of accountability and responsibility, since a participant is essentially in a group of many other participants that might answer. Even when asking a participant by their name specifically, will sometimes leave an awkward silence, as you did not realize the person was at this moment grabbing a snack, a coffee, having a toilet break or busy shooing away their kids from their improvised home office. No response invisible Whenever one of your participants runs into an issue, especially if they’re not an expert at explaining code bugs/errors, you end up asking them to share their screen so you can look what’s going on. Apart from the time spent to share screens and get that working properly, you also distract everyone else in the meeting with the issue of that one participant. In a physical classroom, you can walk up, look over their shoulder, and whisper to help them out. This is much more welcoming than asking the participant to essentially broadcast their mistakes to the entire room. I have found that participants are far less likely to ask for help for this reason alone. Can you share your screen? These two problems alone in my first workshops online before COVID-19 made things quite exhausting; I really disliked the experience. It was awkward, inefficient, and many of my participants lost their attention span and I don’t blame them. I figured I would ask my participants to be present, physically, for my workshops and trainings, if possible. However, after COVID-19 hit this was no longer possible. When I realized all of my future trainings and workshops would be like this, I decided I had to find a better way. Finding a solution When identifying the problems, two main requirements arose: : I need to be able to see and collaborate on the code of my participants. Shared code : I need to be able to see the output that the code of the participant produces. Shared output When searching for a solution to the first problem, I came across many tools. Some examples are simple codeshares like pastebin, Github gists, Codepen, JSFiddle, but these are not meant for live collaboration. and are probably the closest I found to the solution I needed. However, both are closed-source and have their limitations which I figured would end up biting me. CodePen Professor Mode codeshare The final contender is perhaps one you already thought of: , in my case the , or as I like to call it, the “Google Docs of coding”. This puts collaborative code sharing and writing, in what also happens to be my favorite code editor of all time. It is open-source, has an Extensibility API to write or extend upon VS Code extensions and a bunch of other features, most notably . Visual Studio Live Share extension for Visual Studio Code Shared Servers So with this, my first requirement was met, kudos to the Live Share team at Microsoft for creating such an incredible product! Shared servers inspired me for the second requirement. With shared servers, any participant that is connected to your session has an SSH tunnel to you over the port you share in shared servers. This means that they can use on their machines and access a shared API or web server. localhost:<port> However, there are remaining challenges: See the output of backend languages where the output is not a served web application or module My participants will all have their own code, and therefore their own output. How do I easily distinguish and view a specific participant’s output? Seeing an overview of all the outputs of the participants, so I can easily glance at all of them simultaneously to see if I find a participant who is lagging behind or stuck on something See updates of the output whenever a participant saves a file inside their folder without refreshing the page code-workshop-kit This is essentially where , my NPM package, comes in. code-workshop-kit It is a smart development server that is built on top of a revolutionary, buildless, development server called , which is the successor of , built by the guys from . @web/dev-server es-dev-server Open Web Components This server is essentially an abstraction on top of , making it easy to write plugins and middleware for serving files over HTTP, and it has a really good NodeJS API for extending and building on top of it to make your own dev server. This is exactly what I needed to overcome the remaining challenges. Koa opinionated What the code-workshop-kit server does on top of @web/dev-server, is ensure that when serving the main index.html, an app shell component is inserted which, among other things, has: Basic user authentication for participants and hosts An overview page on which the output of every participant is aggregated to Hot Module Replacement for frontend workshops Follow-mode, allowing the host to switch pages on localhost and the participants’ URLs are updated to follow An Admin-only UI bar for toggling dev server settings on the fly There’s many more cool features, to read more about this, ! visit the code-workshop-kit docs How to use it So far, the main use cases are either frontend web workshops or workshops for backend languages, where the terminal is the input/output. So let’s go over those. Having NodeJS and NPM installed is a prerequisite. Frontend Create an empty folder and install code-workshop-kit: mkdir cwk-test && cwk-test && npm init -y && npm i code-workshop-kit cd Open the folder in VS Code. Create a file called : cwk.config.js { : , : [ , , ],
}; export default appTitle 'Welcome to Joren\'s Frontend Workshop' participants "Joren" "Bob" "Alice" This creates the default export that the CWK server uses to read the user provided configuration settings. Now let’s create some starter files for our participants. Create a folder . template In this folder, create : index.html Document Hello <!DOCTYPE html> < = > html lang "en" < > head < = /> meta charset "UTF-8" < = = /> meta name "viewport" content "width=device-width, initial-scale=1.0" < > title </ > title </ > head < > body < > h1 < %> %= participantName </ > h1 < = > script src "./index.js" </ > script </ > body </ > html Let’s also create a starter JavaScript file, : index.js .log( ); console "Hello, <%= participantName %>" Note the special <%= %> tags in which we can place variables that will be filled in by the scaffolder. Read more about that in the scaffolding docs Scaffold these starter files for all participants: npx cwk scaffold You should now see a folder “participants” with a folder for each participant and their starter files. Let’s see it in action: npx cwk run Now check out the browser on . Feel free to invite some others by creating a session in VS Code using the Live Share extension. localhost:8000 If you select a name, you should then see the participant overview, and every participant’s rendered through an iframe. You can click the view buttons to view only one specific participant's output. index.html Simple enough right? But it gets cooler. Right now we render the participant’s webviews through iframes. This is not ideal, especially with a larger number of participants, as iframes are just not that performant. They also live in their own realms, meaning they cannot share dependencies, making this even heavier on the server and slowing down your page. Very often, in the land of frontend, the main entrypoint is a Javascript file: . We then export some sort of template which gets rendered to DOM. This is quite common for Single Page Applications. The benefit of this approach in is that we can use a technique called to reload this exported Javascript module whenever files have changed, without needing a page reset. Furthermore, the overview page can load the module and no iframes are needed, meaning dependencies can be shared easily. index.js code-workshop-kit Hot Module Replacement Let’s change our setup to use this method. In the , edit it to: cwk.config.js { : , : [ , , ], : { : }  
}; export default appTitle 'Welcome to Joren\'s Frontend Workshop' participants "Joren" "Bob" "Alice" targetOptions mode 'module' This will assume an file in the root folder of every participant, which must contain a default export which is either an HTML string value, a DOM Node/Element ( for example) or a lit-html . I’m happy to accept feature requests or contributions for other templating methods, as long as they are not locked behind a compilation step. You can always pre-render with whatever tool or engine you like, and pass the DOM node. index.js document.createElement('div') TemplateResult Delete your inside the folder. Edit the : index.html template index.js .log( ); ; console "Hello, <%= participantName %>" export default `<h1>Hello <%= participantName %></h1>` Delete your folder entirely, and just re-run: participants npx cwk scaffold Then restart the cwk server: npx cwk run You should see the same overview. But this time, things are rendered through modules instead inside iframes. Hot Module Replacement also works now. You can see this by going into for example Bob’s , and change: index.js ; export default `<h1>Hello Bob</h1>` to: ; export default `<h1>Hello Bob!!!!!</h1>` Hit save, and immediately the application will reload the module, and it gets updated in your browser and those of all other participants, without anyone needing to do a thing for it! As a workshop host, you just sit back and watch the outputs change over time as your participants are writing away at their exercises. Backend At this point, many of you will ask: “okay that’s great but what about my backend workshops, where the output is not a served web application or module?”. Instead of using Live Share’s shared terminal feature and giving all your participants a separate terminal with full access on your machine, I created a more safe and user-friendly way of aggregating terminal output, which is the most common method of “output” for backend. The workshop host has control over which command gets run in each participant’s root folder, and just re-run that command when files are changed. Let’s see it in action. Since you have NodeJS installed, I will use a NodeJS example, but I have personally tested this with many other backend languages as well. If you want more information, see docs on using terminal target Change your : cwk.config.js { : , : [ , , ], : , : { : }  
}; export default appTitle 'Welcome to Joren\'s Backend Workshop' participants "Joren" "Bob" "Alice" target 'terminal' targetOptions cmd 'node index.js' Change the inside the folder to create a tiny terminal input/output program: index.js template readline = ( ); rl = readline.createInterface({ : process.stdin, : process.stdout,
});

rl.question( , (country) => { .log( );
  rl.close();
});

rl.on( , () => {
  process.exit( );
}); const require "readline" const input output "Hello <%= participantName %>! Where do you live? " console `You are a citizen of ` ${country} "close" 0 Rerun the scaffolder with -f to force overwriting existing files. npx cwk scaffold -f And rerun the cwk server npx cwk run You will see a slightly different overview page now, because there is now a clear and a rerun button, as well as a terminal input field which is disabled by default. Try saving one of the files of the participant, or click one of the rerun buttons. This will make CWK run inside that participant's folder, and the output is aggregated to the participant's view. You will see a green circle pop up notifying you that a script is running for that participant, and you can now use the terminal input field to and press enter to send. This will send your text to the process' input. node index.js Future At this time of writing, is v1 (v1.0.4 to be precise). That means the API is stable. Me and two others have personally alpha tested with this a fair bit, both for frontend (usually web component related workshops) as well as Java backend workshops. code-workshop-kit The code is open-source, which I think is fair given that I build on top of existing open-source projects. I also want to reach as many teachers as possible and I want to carry my weight during these difficult COVID-19 times. This project is not finished. I will continue working on it for the foreseeable future, as it directly impacts my work as a trainer. Microsoft’s VS Code Live Share extension team were kind enough to reach out to me and we had a very insightful meeting, so I have many ideas on how to further improve (thanks Jonathan Carter and Filisha Shah) . Leverage to allow participants to connect to a session from their browser, without needing to install VS Code & extensions codespaces Collaborate with the live share team to further improve and suggest new features for their extension Leverage the extensibility API of VS Code to further reduce the work needed to be done by the workshop host Create more content on delivering high quality workshops, and supplying out of the box working setups for specific languages/frameworks If you use code-workshop-kit, please do reach out to me, I'd be really happy to know about your experiences and feedback! You can reach me on and , or send me an . Twitter LinkedIn email Also published at https://joren-broekema.medium.com/code-workshop-kit-a-tool-for-remote-code-workshops-e5e538158cf0

Introduction to Code-workshop-kit: a Tool for Remote Code Workshops

Why Another Boilerplate The combination of React and TypeScript is very popular and so is Create React App (CRA). Express is a widely used choice for a webserver. Accordingly, there is no shortage of articles describing how to make them work together. So the question is why we need another one? The answer is multi-faceted: Performance. A script bundle with size 3.5 MB in development cut to ~70 KB in production. Backend implements HTTP caching that further enhances performance yet supports smooth deployment of versioning changes in production. Ability to optionally split your React Application into multiple Single Page Applications (SPA). For example, one SPA can offer an introductory set of screens for the first-time user or handle login. Another SPA could implement the rest of the application, except for Auditing or Reporting that can be catered for by yet another SPA. Seamless debugging. Debug a minified/obfuscated, compressed production bundle and put breakpoints in its TypeScript code using both VS Code and Chrome DevTools. Development build debugging: put breakpoints in the client and backend code and debug both simultaneously using a single instance of VS Code. Containerisation. Docker multi-staged build is used to ensure backend run-time environment is not polluted by client build-time dependencies. It improves security and reduces container storage footprint. Crisp React I hope this functionality sounds interesting enough to introduce to you. It’s a boilerplate project with all the above features. Start by cloning the repository then build the client and start the backend: Crisp React git clone http //github. /winwiz1/crisp-react.git crisp-react
yarn install && yarn s: com cd star t:prod If the last command ends in error because yarn is not installed, run and repeat the command. npm install yarn -g Once the message "Starting the backend..." appears on the console, navigate a browser to localhost:3000. It should display this page: The React application built by the preceding command consists of two SPAs called 'first' and 'second'. The name determines the landing page of the SPA so we have two pages: and . The browser is displaying the first landing page but its path is not shown in the navigation bar. The reason is simple: redirection. To understand why is it needed, let's recollect how SPA works. yarn start:prod /first.html /second.html SPA Background When you choose ComponentA or ComponentB using the menu, the browser navigates to or . However these paths are internal to the SPA, the backend is not aware of it and keeps 'thinking' there were no page transitions. Suppose a 'curious user' typed in the path and hit Enter. The backend is not prepared to serve anything except for the landing page(s) so it would respond with 404 "Not Found" error and it wouldn't look good. Had the user chosen to refresh the page, the outcome would have been the same. /a /b /a As a protection against 'curious users' and refreshes, any SPA-aware webserver instead of 404 error uses redirects to the landing page of the SPA. Which in our case is served if browser is manually pointed 
to or or etc. Such tolerance usually has its limits due to security considerations and navigating to something like does trigger an error. /a / /invalid /invalid/valid SPA Customisation There is hopefully nothing wrong with our two sample SPAs except for the not overtly meaningful names, 'first' and 'second'. Let's rename it to 'login' and 'app' while adding the 3rd 'reporting' SPA. In the file modify the SPA Configuration block: client/config/spa.config.js SPAs = [ SPA({ : , : , : }), SPA({ : , : , : }),
  ];
  SPAs.appTitle = ; /****************** Start SPA Configuration ******************/ let new name "first" entryPoint './src/entrypoints/first.tsx' redirect true new name "second" entryPoint './src/entrypoints/second.tsx' redirect false "Crisp React" /****************** End SPA Configuration ******************/ by changing the names. Then copy and paste the 2nd SPA configuration to create another SPA. Finally, name the 3rd SPA 'reporting': SPAs = [ SPA({ : , : , : }), SPA({ : , : , : }), SPA({ : , : , : }),
  ];
  SPAs.appTitle = ; /****************** Start SPA Configuration ******************/ let new name "login" entryPoint './src/entrypoints/first.tsx' redirect true new name "app" entryPoint './src/entrypoints/second.tsx' redirect false new name "reporting" entryPoint './src/entrypoints/second.tsx' redirect false "DemoApp" /****************** End SPA Configuration ******************/ To try the new SPAs we need to stop the backend we started earlier. Press , rebuild and start the backend using another command. Then open a private browser tab to avoid caching or history issues related to the old names. Point this tab to localhost:3000 and use the menu to navigate around the app. Note the landing pages have changed to and . The bundle names are visible via the View Page Source browser's menu and did change as well. Control+C yarn start:prod /login.html /app.html The 3rd SPA is available at It is unsurprisingly identical to the 'app' SPA because we copied and pasted its configuration. /reporting.html. If multiple SPAs are not needed, simply comment out or remove all SPA configuration entries except for one, rebuild and you are done. Press to stop the backend.  We are going to start it in the next section and don't want to have several backend instances fighting for the same port. Control+C Debugging Some bugs are tricky to pinpoint and may require setting breakpoints in both the backend and the client app. Let's see how it can be done using Chrome DevTools and VS Code with 'Debugger for Chrome' extension. To start, restore the SPA configuration file, then build the solution and open the workspace in VS Code: git checkout ./client/config/spa.config.js
yarn build
code ./crisp-react.code-workspace In VS Code activity bar on the far left-hand side, click on Debug and start the debugging configuration: Debug Client and Backend (workspace) Wait until Chrome starts and displays the landing page of the 'first' SPA we saw earlier.  Open Chrome DevTools. On the 'Sources' tab use 'Filesystem' and then 'Add folder to workspace' to add the directory. Chrome will display a toolbar asking for permissions to access this directory. Click on the 'Allow' button. The content of the added directory will be shown with green dots superimposed on the source file icons: client/src ComponentC doesn't have a green dot because it cannot be found in the source maps for the currently loaded script bundle. Which makes sense as it belongs to another SPA and its bundle. Open the file and put a breakpoint on line 14. Use the landing page menu to choose the ComponentB. The breakpoint  will be hit with the line 14 highlighted in light blue: ComponentB.tsx VS Code apparently knows about that and displays a yellow hollow marker against the same line. Click on the blue marker to remove the breakpoint and resume execution using either Chrome DevTools or VS Code. Close Chrome DevTools. Now let's focus on debugging in VS Code.  Place a breakpoint on the same line in and another breakpoint in the file on line 59. client/src/components/ComponentB.tsx server/src/Server.ts Note that VS Code can mark a breakpoint with a circle that is grey and hollow rather than red and solid, referring to it as 'Unverified breakpoint'. You can check the breakpoint has been set and marked with solid red circle by highlighting the relevant process (client or server) on VS Code Debug sidebar in the CALL STACK view: To test both breakpoints, choose the ComponentC from the menu. The server breakpoint will be hit.  Remove or disable the breakpoint (unless you are comfortable to keep resuming each time it's hit), resume execution and use the menu to go back to the First SPA. Choose the ComponentB. The breakpoint set in this component will be hit. If you modify , for instance alter the text displayed on the landing page, the code will be recompiled. As you are typing, note the compilation progress in the client Terminal followed by automatic browser refresh. The new content should be shown on the landing page. This is called Live Reloading. In a similar manner, modifying will cause recompilation visible in VS Code in the second (server) Terminal. client/src/components/Overview.tsx server/src/Server.ts To finish debugging stop both client and server processes. Use VS Code Debugging toolbar (click the ‘Stop’ button two times) or press Control+F5  twice. There are several debugging scenarios described in the project README. We went through of those, I hope you will find the others to be useful too. one Containerisation To build and run a Docker container execute or . The file can also be executed from an empty directory in which case uncomment the two lines at the top. Moreover, it can be copied to a computer or VM that doesn't have NodeJS installed. The only prerequisites are Docker and Git. start-container.cmd start-container.sh Next Steps After reading the and the SPA configuration file comments, consider customising SPAs, UI and adding an API endpoint to the backend. README By following the advise in the relevant README , you should avoid frequent pitfalls of React-Express projects such as getting CORS issues or running webpack-dev-server in production. section Happy Reacting in the crisp clear waters!

React + Express + Typescript Boilerplate with Performance and Extended Functionality

We are going to build a simple Front End that will use Scatter for logging in and authorising actions on the EOS blockchain Once upon a time, the only wallet I knew was the one that carries my lunch money. Today there are numerous wallets out there, but instead of keeping your money they keep your private keys. Now among all the wallets out there I have chosen to work with Scatter due to it’s popularity among the EOS community. Most of the EOS Dapps being built these days, almost all of them supports Scatter. Scatter has also become increasingly popular among Ethereum and Tron, making it a solid investment for your future Dapp development. Setting up Scatter Scatter used to come in the form of a Chrome plugin, but now it has officially dropped that in favour of a full native app. If you have not installed Scatter, the first step you need to do is download it from its GitHub page here. For the purpose of this guide we are going to import our EOS account we created on the CryptoKylin testnet the other day into our Scatter wallet. If you have no idea on how to create a testnet account, I have already written about it on my first guide under the EOS Account section, click here. Now once you have your testnet account name and private key, fire up Scatter. On your first run it will ask you to create a password. You will need this password to unlock your wallet when ever you want to use it again at a later time. Since we are planing to import an EOS testnet account, we must add the testnet details to Scatter first. The way to do this is to go to the Settings -> Networks. You will find the Settings button (shape of a gear icon) on the top right corner. Once again you need to key in your password. CryptoKylin Testnet details Under the “Your Networks” tab, click on the Add button. Key-in the details according to the screenshot above. At the time of this writing these inputs are still valid, however to confirm that you have the latest inputs you should always ask in their telegram group here. Import Keys Ok now go back to the main interface of Scatter. Click on the “Add Keys” button on the bottom left corner. Add Keys menu You will see 3 options, click on the “Import Key” button. Import Key menu Another 3 options will be shown, click on the first button “Text” since we have our private key in the text format. Go ahead and paste your testnet private key. Since every account you create on the testnet comes with an Owner and Active key, for simplicity sake you can just import your Active key. Linked Accounts Since we have already added the CryptoKylin details under the networks settings, Scatter automatically links your private key to your account name on the CryptoKylin testnet. You can view this under the Linked Accounts tab. Optionally you can give a nicer name for this key under the “Key Name” text box above. I am going to name it youraccname1@active. At this point, we have completed all the setup necessary for Scatter to work with our Front End. Here is a summary of the main tasks we have accomplished so far: Created a testnet account Added the testnet details to Scatter Imported our testnet private key to Scatter In the next section we will develop the Front End so it will talk with Scatter nicely. You will want to keep Scatter app running in the background so that our Front End detects it. Front End , I have written about building a simple Front End for EOS. It was a simple Dapp that is able to login the user with their account name and private key. To make this Dapp more practical, we are going to modify it so that it can work with Scatter. In my previous guide When ever an action needs to be performed on the blockchain; for example logging in, with Scatter the user does not need to key in their private key every time. On the front-end side we do not need to cache their private key anymore, as this could cause vulnerability issues. By using Scatter, this is how it is going to work from now on: every time we need to perform an action, we invoke Scatter from it’s javascript API. Scatter will then request the user for their permission on which key to use to perform the action. After the user has authorised then Scatter will return us a signature object that we can use to sign the transaction on the blockchain. Super simple, clean and more secure! I have modified our to now work with Scatter. Let’s get started by cloning my latest Github project and I will walk you through the main changes. Open terminal and type this: previous front-end $ git clone https://github.com/shankqr/eos-scatter.git Once all the files have been cloned to your local machine. Get into the project directory and install all the dependencies $ cd eos-scatter$ npm install To avoid any babel/webpack issues with our Vue project, type this: npm i -D @babel/runtime VUEX The first thing we are going to do is store the status of our login with VUEX. VUEX is quite similar to Redux as it is both inspired by FLUX, accept it’s more suited for Vue. I find overall using VUEX more simpler than Redux, however both these state management framework are equally good in my opinion. //store.jsimport Vue from 'vue';import Vuex from 'vuex'; Vue.use(Vuex); export default new Vuex.Store({state: {loggedIn: false},mutations: {loginStatus(state, status) {state.loggedIn = status;}},getters: {loggedIn: state => state.loggedIn},actions: {}}); Here I created a state called loggedIn and set it to false, then I created a mutation called loginStatus that just changes the value for loggedIn. Lastly I added a getter so we can retrieve the value of our loggedIn state. Ok let’s see how we are going to access this newly created state on the UI part. I have modified the AppTopBar.vue component to include a Logout button.  <template><span><v-toolbar app color="black darken-4" dark><v-spacer class="hidden-md-and-up"></v-spacer><v-toolbar-title>{{appTitle}}</v-toolbar-title><v-spacer></v-spacer><v-btn ="handleLogout()" v-if="$store.state.loggedIn">Logout</v-btn></v-toolbar></span></template> @click <script>export default {name: 'AppTopBar',data() {return {appTitle: 'My EOS Dapp'};},methods: {handleLogout: async function() {this.$store.commit('loginStatus', false);this.$router.push('/');}}};</script> <style scoped></style> The logout button has been wired to the handleLogout method and it calls the $store mutation named loginStatus. This action will set our loggedIn state to false. Pretty simple logic here. Now let’s go through the most important part which is the API calls to work with Scatter. Scatter API From early on I have stored all EOS related methods in a class called EosService. We are going to extend this class so that it is able to talk with Scatter. //EosService.jsimport { Api, JsonRpc } from 'eosjs';import ScatterJS from 'scatterjs-core';import ScatterEOS from 'scatterjs-plugin-eosjs2'; const endpoint = ' ; // kylinconst network = {blockchain: 'eos',protocol: 'https',host: 'api.kylin.alohaeos.com',port: 443,chainId: '5fff1dae8dc8e2fc4d5b23b2c7665c97f9e9d8edf2b6485a86ba311c25639191'}; https://api.kylin.alohaeos.com:443' class EosService {constructor(dappName, contractAccount) {this.dappName = dappName;this.contractAccount = contractAccount;ScatterJS.plugins(new ScatterEOS());this.rpc = new JsonRpc(endpoint);window.ScatterJS = null;} connect = async () => {await ScatterJS.scatter.connect(this.dappName).then(connected => {if (!connected) return console.log('Failed to connect with Scatter!');this.scatter = ScatterJS.scatter;}); await this.scatter.getIdentity({ accounts: [network] }).then(() => {this.account = this.scatter.identity.accounts.find(e => e.blockchain === 'eos');}); if (this.account === null) return false; return true;}; transaction = async (action, data) => {this.api = this.scatter.eos(network, Api, { rpc: this.rpc }); const resultWithConfig = await this.api.transact({actions: [{account: this.contractAccount,name: action,authorization: [{actor: this.account.name,permission: this.account.authority}],data: {...data}}]},{blocksBehind: 3,expireSeconds: 30});console.log(resultWithConfig);return true;};} export default EosService; To work with Scatter, we first need to import 2 libraries: ScatterJS and ScatterEOS. We then specify the constants to store the endpoint and network details, in our case we will be using the testnet details. We will be only needing to main methods here, which is the connect and transaction. Scatter: connect method In the connect method we simply try to link a Scatter account with our Dapp. Scatter will then prompt the user to select an account they would like to use with our Dapp. Scatter: transaction method In the transaction method, we are invoking an action on the EOS smart contract. What Scatter will do in this case is to prompt the user with a dialog to allow or deny this action. Wrapping Up For the final section of this guide let’s have a look at the Login page where we use our EosService.  <template><v-container><v-layout row class="text-xs-center"><v-flex xs3 style="background-image: url(' )"><v-card height="500px"></v-card></v-flex><v-flex xs4 class="grey lighten-4"><v-container style="position: relative;top: 13%;" class="text-xs-center"><v-card flat><v-card-title primary-title><h4>Login</h4></v-card-title><v-form><v-card-actions><v-btn ="handleLogin()" primary large block>Login</v-btn></v-card-actions></v-form></v-card></v-container></v-flex></v-layout></v-container></template> http://cdn.wallpapersafari.com/7/86/gqiGH7.jpg' @click <script>import EosService from '@/eosio/EosService'; export default {data() {return {accountName: '',privateKey: '',eosio: null};},methods: {handleLogin: async function() {if (this.eosio === null) {this.eosio = new EosService(process.env.VUE_APP_DAPP_NAME,process.env.VUE_APP_SMART_CONTRACT_NAME);} if (!(await this.eosio.connect()))return console.log('Failed to get Scatter account'); if (await this.eosio.transaction('login', { user: this.eosio.account.name })) {this.$store.commit('loginStatus', true);this.$router.push('home');}}}};</script> Here we simply import our EosService, initialise our class and pass in the parameters into the class constructor. We then call the connect() method and the transaction() method passing in the name of the action we want to call on the smart contract and it’s input data. If it’s successful the method will return true and we change our loginStatus state to true and route the user to our main page. Dapp main page, console prints out the transaction details If you open the chrome developer tools you should be able to see the transaction details printed out on the console. Congratulations! we have successfully integrated Scatter to your Dapp. We have reached the end of this guide, but I would love to hear what you guys are working on. If you need help don’t be afraid to . reach me

How to integrate Scatter with your EOS Front End

We are going to build a simple Front End that interacts with an EOS smart contract Our simple front end: Login Page I have always been a big fan of React from the very beginning, but lately I have been playing around with Vue and have to admit that I really fell in love with it for it’s simplicity. To keep things simple as possible for you, I have decided to use Vue to build our front end this time. NOTE: If you have not tried out Vue, their official documentation is the best place to start. Create a Vue Project Start by installing Vue, open up terminal and type this: npm i -g @vue/cli Now that Vue is installed we are going to use it’s CLI to create our project vue create eos-login When prompted choose “Manually select features” then, use the space bar to select Babel, Router and Vuex feature. For the rest of the questions you can just choose the defaults. Once the Vue CLI have created our project, we can change directory into it and add plugins. We are going to add the Vuetify plugin for helping us with the design. cd eos-login vue add vuetify You will be asked a series of questions, just follow my answers like bellow: vuetify options Ok lastly we will need to install EOS official javascript library so that we can easily make calls to the EOS blockchain. npm i eosjs@beta NOTE: The npm package eosjs@beta is the latest compared to just eosjs By now you will have a perfect project setup to start coding. npm run serve Follow the link on your browser and you should see the default Vue template up and running! Deploy our Smart Contract Before we start coding the front end let’s deploy our latest smart contract to the EOS blockchain. I have written a simple smart contract that has a ‘users’ table and a login method that accepts an EOS account as it’s input. The login method will store the account in the users table if no records already exist for that name. However if there is already a record, it will increment the reward_points by 1 instead. The login also ensures that only valid EOS account can enter. Let’s go ahead and deploy this contract . I have previously written a step by step guide on how to accomplish this, please click here. Coding the Front End part Now that we have our hello contract deployed, we can resume our work on the front end. Open the eos-login project folder in VSCode (or you favourite IDE), we will be adding 4 files to our project: AppTopBar.vue under the components folder EosService.js under the eosio folder (create this folder) Login.vue under the views folder .env under the project root folder Add this files to your project. Your project structure should now look like bellow. Project directory structure Let’s start by coding the AppTopBar component. In Vue, components can be easily added to pages making it very re-usable. The AppTopBar component is simply a header bar with a title of our application.  <template><span><v-toolbar app color="black darken-4" dark><v-spacer class="hidden-md-and-up"></v-spacer><v-toolbar-title>{{appTitle}}</v-toolbar-title></v-toolbar></span></template> <script>export default {name: 'AppTopBar',data() {return {appTitle: 'My EOS Dapp'};}};</script> <style scoped></style> Now open App.vue under the src folder to import our component. Notice that AppTopBar has been format as <app-top-bar> inside the template.  <template><v-app><app-top-bar></app-top-bar><v-content transition="slide-x-transition"><router-view></router-view></v-content></v-app></template> <script>import AppTopBar from '@/components/AppTopBar'; export default {name: 'App',components: {AppTopBar}};</script> For our application we will have 2 main page which is the Login page and the Home page. On the App.vue we are using the Vue Router to link to both pages with the <router-view></router-view> tag. Open the router.js file to edit the paths. //router.js import Vue from 'vue';import Router from 'vue-router';import Login from './views/Login.vue'; Vue.use(Router); export default new Router({mode: 'history',base: process.env.BASE_URL,routes: [{path: '/',name: 'login',component: Login},{path: '/home',name: 'home',component: () => import('./views/Home.vue')}]}); Edit our Home.vue  <template><v-card-title primary-title><h4>Welcome to my Dapp main page!</h4></v-card-title></template> <script>export default {components: {}};</script> Create our Login.vue  <template><v-container><v-layout row class="text-xs-center"><v-flex xs3 style="background-image: url(' )"><v-card height="500px"></v-card></v-flex><v-flex xs4 class="grey lighten-4"><v-container style="position: relative;top: 13%;" class="text-xs-center"><v-card flat><v-card-title primary-title><h4>Login</h4></v-card-title><v-form><v-text-fieldv-model="accountName"prepend-icon="person"name="AccountName"label="Account Name"></v-text-field><v-text-fieldv-model="privateKey"prepend-icon="lock"name="PrivateKey"label="Private Key"></v-text-field><v-card-actions><v-btn ="handleLogin()" primary large block>Login</v-btn></v-card-actions></v-form></v-card></v-container></v-flex></v-layout></v-container></template> http://cdn.wallpapersafari.com/7/86/gqiGH7.jpg' @click <script>import EosService from '@/eosio/EosService'; export default {data() {return {accountName: '',privateKey: ''};},methods: {handleLogin: function() {EosService.login(this.accountName, this.privateKey).then(() => {this.$router.push('home');}).catch(err => {alert(err.toString());});}}};</script> The Login.vue page calls the login function on EosService and passes the inputs for account name and private key. If the login function returns success it simply redirects to the Home.vue page. Now before I dive into the EosService login function, let’s edit our .env file with the correct values. Open the .env file under the project root directory. VUE_APP_SMART_CONTRACT_NAME="youraccname1"VUE_APP_NODE_ENDPOINT=" " https://api.kylin.alohaeos.com:443 Set the value for VUE_APP_SMART_CONTRACT_NAME to the account name you created earlier on the Testnet to deploy the hello contract. The value for VUE_APP_NODE_ENDPOINT should be then set to a Testnet endpoint, in this case I am using the CryptoKylin Testnet. Subsequently if you have deployed your smart contract on the Mainnet then you should set the value of the endpoint to any of the . 21 main block-producers EosService Finally let’s look into the code for the EosService.js library I created. This is where the bulk of action is happening. //EosService.js import { Api, JsonRpc } from 'eosjs';import JsSignatureProvider from 'eosjs/dist/eosjs-jssig'; async function invokeAction(action, dataValue) {const rpc = new JsonRpc(process.env.VUE_APP_NODE_ENDPOINT); const privateKey = localStorage.getItem('private_key');const signatureProvider = new JsSignatureProvider([privateKey]); const api = new Api({rpc,signatureProvider,textDecoder: new TextDecoder(),textEncoder: new TextEncoder()}); try {const resultWithConfig = await api.transact({actions: [{account: process.env.VUE_APP_SMART_CONTRACT_NAME,name: action,authorization: [{actor: localStorage.getItem('name_account'),permission: 'active'}],data: dataValue}]},{blocksBehind: 3,expireSeconds: 30});return resultWithConfig;} catch (err) {throw err;}} class EosService {static login(acc, key) {return new Promise((resolve, reject) => {localStorage.setItem('name_account', acc);localStorage.setItem('private_key', key);invokeAction('login', { user: acc }).then(() => {resolve();}).catch(err => {localStorage.removeItem('name_account');localStorage.removeItem('private_key');reject(err);});});}} export default EosService; Basically what we are doing here is creating an API transaction by passing in the parameters of the .env file earlier. For this to work we need to create a signature provider with an EOS account private-key to access the smart contract. Since this is meant to be a simple tutorial we are directly dealing with the private-key here, however in a real world application it is best to integrate with a 3rd party wallet to handle the creation of the signature provider. That way you do not have to ask your users for their private-key directly which is insecure. NOTE: Scatter is a good example of a 3rd party wallet out there. They have established them-self as one of the trusted wallet solution through out the EOS community. Interestingly they already have an existing API for you to integrate with your applications. Ok we are done with all the front end code. If you have reached to this point, give yourself a big pat on the back for following through. I believe we have completed a bare minimum front end for any EOS smart contract. All the work you will be doing in the future will most probably be built upon this base. I have posted this project files on GitHub: . Now will be a good time for you to compare your code and mine to make sure everything is the same before we continue. https://github.com/shankqr/eos-login Run our Code Go ahead, get into our project directory and run the code: npm run serve Follow the link on your browser: , your screen should look like this: http://localhost:8080/ Enter the details Enter your account name along with the private key that you have created previously on the Testnet. Click on Login. Dapp main page If you have entered everything properly you will be directed to our Home page after a few seconds. Congratulations! you have just built your first Dapp. Before we end this series, let us just check to see if our smart contract have registered this login into our users table. As you can see the return that your record has been added to the users table. Now let’s test to see if the reward_points is incremented if we login again. Refresh your browser and try to login again. After login, let’s check again: Fantastic! Our smart contract is doing what it was programmed to do. Don’t you just love the Blockchain, it is just so reliable. Summary You have learned how to: Create an empty Vue project Add a Vue plugin Install the EOS official javascript library Write an EOS smart contract that can store data in tables Connect a front end to EOS I hope you enjoyed this guide, please leave your comments bellow. I am thinking about writing on Scatter wallet integration next. I would love to hear your thoughts. Follow me on LinkedIn!

How to build a simple Front End for your EOS smart contract

In this tutorial, we will be creating a sample React application using and automate it using Selenium WebDriver, covering varied test cases. create-react-app Selenium Icon. Why selenium? Selenium WebDriver provides a programming interface to create and execute test cases. It automates our development and every developer must now to write unit test cases for their work to manage their code better. Prerequisites (NPM comes with Node.js, you don’t need to install it separately) Node.js & NPM Selenium WebDriver & Chromedriver Geckodriver Mocha Firefox and Chrome browsers. Let’s code Let’s straight away jump into development. Create a project called “ ” using create-react-app. react-selenium $ npx create-react-app react-selenium$ cd react-selenium$ npm start Now, you have your app ready, running in the port 3000. You can access it via http://localhost:3000 We will install the above prerequisites in our app. $ npm i selenium-webdriver chromedriver geckodriver --save$ npm i mocha --save-dev Now in your root directory, create a folder called and inside of it, create a file called . Refer the final for reference. test test.js source code In test.js, add the following code in it. /*** Dependency Modules*/var assert = require("assert").strict;var webdriver = require("selenium-webdriver");require("geckodriver"); // Application Serverconst serverUri = " ";const appTitle = "React Selenium App"; http://localhost:3000/# /*** Config for Chrome browser* {webdriver}*/var browser = new webdriver.Builder().usingServer().withCapabilities({ browserName: "chrome" }).build(); @type /*** Config for Firefox browser (Comment Chrome config when you intent to test in Firefox)* {webdriver}*//*var browser = new webdriver.Builder().usingServer().withCapabilities({ browserName: "firefox" }).build();*/ @type /*** Function to get the title and resolve it it promise.* {[type]} [description]*/function logTitle() {return new Promise((resolve, reject) => {browser.getTitle().then(function(title) {resolve(title);});});} @return /*** Sample test case* To check whether the given value is present in array.*/describe("Array", function() {describe("#indexOf()", function() {it("should return -1 when the value is not present", function() {assert.equal([1, 2, 3].indexOf(4), -1);});});}); describe("Home Page", function() {/*** Test case to load our application and check the title.*/it("Should load the home page and get title", function() {return new Promise((resolve, reject) => {browser.get(serverUri).then(logTitle).then(title => {assert.strictEqual(title, appTitle);resolve();}).catch(err => reject(err));});}); /*** Test case to check whether the given element is loaded.*/it("Should check whether the given element is loaded", function() {return new Promise((resolve, reject) => {browser.findElement({ id: "sel-button" }).then(elem => resolve()).catch(err => reject(err));});}); /*** End of test cases use.* Closing the browser and exit.*/after(function() {// End of test use this.browser.quit();});}); Quite long right? I will explain part by part in it. /*** Dependency Modules*/var assert = require("assert").strict;var webdriver = require("selenium-webdriver");require("geckodriver"); Add these lines at the top, which are the required dependencies to automate our development. is the default Node.js library so no need to install it. is the base driver for selenium to run and is essential to run our test cases in other browsers than chrome. assert Selenium-WebDriver geckodriver // Application Serverconst serverUri = " ";const appTitle = "React Selenium App"; http://localhost:3000/# We are going to work on two test cases. First, we are going to load our application using Selenium by providing the required URI, get our app title once our application loads and checking it with the given appTitle value. Second, we are going to find an element in our application to check whether the given element is loaded, which we are going to add it later in this post. Visit file in the folder and change the value as . index.html public title React Selenium App /*** Config for Chrome browser* {webdriver}*/var browser = new webdriver.Builder().usingServer().withCapabilities({ browserName: "chrome" }).build(); @type /*** Config for Firefox browser (Comment Chrome config when you intent to test in Firefox)* {webdriver}*//*var browser = new webdriver.Builder().usingServer().withCapabilities({ browserName: "firefox" }).build();*/ @type It’s time to configure selenium by providing proper inputs like in which browser the test cases should load, what are all the configurations needed etc. Here first browser config value contains configuration for Chrome browsers and I have commented configurations for Firefox browsers. You can do vice-versa when you are ready to test in Firefox. /*** Function to get the title and resolve it it promise.* {[type]} [description]*/function logTitle() {return new Promise((resolve, reject) => {browser.getTitle().then(function(title) {resolve(title);});});} @return Sample function to get the title of the browser using Selenium-WebDriver inbuilt method called and resolving it using Promise. getTitle() /*** Sample test case* To check whether the given value is present in array.*/describe("Array", function() {describe("#indexOf()", function() {it("should return -1 when the value is not present", function() {assert.equal([1, 2, 3].indexOf(4), -1);});});}); Just a sample test case to make you feel more comfortable. Here we are checking whether value 4 present in the given array [1, 2, 3]. In this case, it will return -1 since it is not present, which is equal to -1 (RHS). So the test case is passed. LHS = RHS. /*** Test case to load our application and check the title.*/it("Should load the home page and get title", function() {return new Promise((resolve, reject) => {browser.get(serverUri).then(logTitle).then(title => {assert.strictEqual(title, appTitle);resolve();}).catch(err => reject(err));});}); In this test case, the string given in the denotes the name of the test case. it We are returning the Promise object because Mocha handles promise objects efficiently and it will be easy to manage our test cases better. After, we are first opening our app by providing the . After that, we are calling the function to get the title of our app and passing the title value to the next callback function. serverUri logTitle Using method, we are comparing title(LHS) with appTitle(RHS). assert.strictEqual Finally, we are resolving it. If those values don’t match, we are rejecting it. /*** Test case to check whether the given element is loaded.*/it("Should check whether the given element is loaded", function() {return new Promise((resolve, reject) => {browser.findElement({ id: "sel-button" }).then(elem => resolve()).catch(err => reject(err));});}); For this second test case, let’s add a button in our App.js file and check whether the button is loaded. Open file and add the following code after tag. App.js <p> <button id="sel-button">Click me!</button> (inbuilt Selenium-WebDriver method) find for the element using the given id in our app and we are resolving it when we find the element and rejecting it when we fail to find the element. browser.findElement sel-button /*** End of test cases use.* Closing the browser and exit.*/after(function() {// End of test use this.browser.quit();}); Finally, after the end of test cases, we are closing the browser and it’s instance. Run the test-case Now, we are going to run these test cases. Add the below line (command) in the script object in your package.json file. "s-test": "mocha test" It’s time to run. From your root directory, run the following command as follows. $ npm run s-test Now you can see your test cases are running in your browser automatically and it gets closed after the test cases are over. Mocha Test Cases Result. You have automated your development. Thank you. Final source code can be found . here References For more API methods on Selenium WebDriver, visit, _Advancing ahead in this Selenium tutorial series, we would be pressing on various commonly and routinely used Selenium…_www.softwaretestinghelp.com 25 Top Selenium WebDriver Commands That Every Automation Tester Must Know _Edit description_seleniumhq.github.io selenium-webdriver/lib/webdriver.IWebDriver _In this tutorial, we will be using advanced JavaScript syntax in our app to maintain code as per latest standards and…_medium.com Use ES6 JavaScript syntax (require, import etc.) in your Front end project.

Stories, News & Mentions about APPTILE

Apptile’s Stories on HackerNoon

Apptile's News & Mentions