DXis in the Application Development Tools Industry

I want all involved in development to think about other users. Not about those who use your application to solve their problems. But those who extend your app, run it in production and integrate with other systems. About developers, operations, SREs and many others who make your business running. Those behind the curtains. I want you to think about the Developers Experience (DX). The problem Working with different businesses and in outsource companies I’ve spot following tendency: The main focus is on business requirements and UI features of built application. Because this is the first thing that real users will see. A client who ordered a new feature would like to see a pretty demo and understand that money invested is working. Such priority looks logical and right. But problems are hiding behind such thinking. always There are many other users behind the curtains. Almost nobody thinks about developer experience (except IT-focused products). Giving priority only to business features and UI is not enough for some solutions. Nowadays all businesses are digital. They integrate with many systems, chats, banks, you name it. There is always some development work happening and many of them don’t focus on DX. Which is bad. It is bad because engineers also should feel happy using your product. If they struggle, you as a business might have loss of trust or reputation. All users of your product are special. Yes, they all have different needs, but meet those needs. Culture DX is also about product vision. It is something that should be in your development team. It should become part of a culture. Understand what you create. Not from specifications but from the real users perspective. Frontend developers are more product-oriented than backend developers. They focus on users and their experience. Backend developers focus on algorithms and data structures. I know that there are backend developers who also think about their users. This article is not about them. The product team and people who have vision should teach others to see problems from the real users perspective. If you would like to bring innovations and raise the quality of the product — such thinking should become part of you. Bad DX examples What experience should engineers avoid trying to use your application? This is an opinionated short list of bad DX examples. If you have something to add — welcome to the comment section below. Bad API design Take a look at the following: GET     /users
GET     /users?id={userID}
NEW     /users/create
POST    /users/update?id={userID}
DROP    /user/{userID} Do you feel pain looking at this? I do. It’s a mix of different things Semantics are not followed Not easy to understand straight away what is happening Not standard HTTP methods are in use (but this is fine according to ). RFC 2616 What is good is that it works. But it would be a lot better if it looked like this: GET       /users
GET       /users/{userID}
POST      /users
PUT       /users/{userID}
DELETE    /user/{userID} Clean. Without looking at documentation such API already starts to give clues. Many frameworks ( , , , etc.) suggest following design of REST APIs by default. Actually, Roy Thomas Fielding was the first who . To start developing taste in API design take a look at or to get started. Ruby on Rails Laravel Play proposed REST this resource this article Another thing that I would like to mention is deep nested objects in API responses. Objects are trees and sometimes those trees grow like real trees. Very tall and dense. It is not good when your response object looks like this: { : , : , : [
    { : , : , : [
        { ... }
      ]
    }
  ]
} "id" "001" "value" "some value" "child" "id" "002" "value" "another value" "child" To get needed values you need to traverse a graph. Algorithmic complexity to parse a graph is ( ). And it’s a lot. There might be too many nodes to traverse. It would be better to flatten such object. O(V+E) DFS [
  { : , : },
  { : , : ,
  },
  { : , : ,
  }
] "id" "001" "value" "some value" "id" "001:002" "value" "another value" "id" "001:002:xxx" "value" "and another value" Much better. And this might be a final variant if the return object is small. Parsing the following structure will take (because of one loop). Nice. And reading such structure is easier. Is it possible to lower search to ? O(n) O(1) { : { : , : }, : { : , : ,
  }, : { : , : ,
  }
} "001" "id" "001" "value" "some value" "001:002" "id" "001:002" "value" "another value" "001:002:xxx" "id" "001:002:xxx" "value" "and another value" Now it is . You can specify a key and extract value without iterating an object. Some may recall Redux by looking at the last example. O(1) State Shape Normalization TIP: Use the following approach to store objects under keys in cache. Solutions provided here are not silver bullets. Key takeaway: Keep your objects as flat as possible. Take a look at your APIs. Can somebody’s life be simplified? Configuration properties chaos Sometimes configuration properties are treated not seriously. Take a look at this snippet: base.url=http://localhost:8080 = jobs.disabled=true
extract.values.and.save.period.hours=5
send.email.each.12.hours=true port 1313 Naming is strange and hard to read Hard to follow logic (because there is no logic) Time unit is big. It might be that there are properties set in other time units than hours It’s hard to figure out the meaning of some properties by their names etc. Treat configuration properties as first-class citizens. Developers and Ops interact with your application using properties. If it is not clear how to use them — mistakes may arise. Additionally it is a sign about the bad quality of your product. How to fix this? server.address=127.0.0.1
server.port=80 jobs.extract_reports.enabled=false
jobs.extract_reports.interval=18000
jobs.extract_reports.destination=/tmp/reports
jobs.extract_reports.email_notifications=false # Network address (server.address) to which the server should bind # and listen port for incoming HTTP requests (server.port). # Default: # Job to extract and save reports to storage. # If enabled (jobs.extract_reports.enabled) job will # run every 5 hours (jobs.extract_reports.interval in seconds) and save # reports to defined destination (jobs.extract_reports.destination). # # Enable email notifications # (jobs.extract_reports.email_notifications) to send summary # of jobs done during the day. # Default: Comments added — more context given Sensible defaults are setAll properties are logically grouped Application with set defaults will be able to start without extra configuration For inspiration I would recommend to take a look at: redis.conf postgresql.conf Logs with no meaning and action Logs are the main interface of your app for the Ops team. If logs lack context it might lead to long investigations of a problem. [ : : ] ERROR Exception happened
com : Base Exception
at com (HomeController : ) ~[bin/:na]
at sun (Native Method) ~[na: . _45]
...
at org (DispatcherServlet : ) ~[spring-webmvc- . : . .RELEASE]
at org (FrameworkServlet : ) [spring-webmvc- . : . .RELEASE]
at org (FrameworkServlet : ) [spring-webmvc- . : . .RELEASE]
at javax (HttpServlet : ) [tomcat-embed-core- . : . ]
... 12 40 45 .ekiras .exception .BaseException .ekiras .controller .HomeController .ex1 .java 21 .reflect .NativeMethodAccessorImpl .invoke0 1.8 0 .springframework .web .servlet .DispatcherServlet .doService .java 893 4.2 4 .RELEASE .jar 4.2 4 .springframework .web .servlet .FrameworkServlet .processRequest .java 969 4.2 4 .RELEASE .jar 4.2 4 .springframework .web .servlet .FrameworkServlet .doGet .java 860 4.2 4 .RELEASE .jar 4.2 4 .servlet .http .HttpServlet .service .java 622 8.0 30 .jar 8.0 30 Such a log only states that something bad happened. For those who don’t have access to the code of your app this is almost zero information. Stacktrace will not give information on how to solve the issue. 12:40:45] the database (db.internal/app) failed. Check datasource property application configuration ERROR Connection to in The message above is clearer because it states directly: What is the problem — DB connection failed How this error can be fixed — check property datasource Usually, machines collect logs first and after humans read them. If this is the case, write log in JSON or structured text formats: = =error = =500 = time "2020-06-14T01:27:38-04:00" level msg "Connection to the database (db.internal/app) failed. Check datasource property in application configuration" status_code path "/about" With the example above, logs can have more context like response status code and path that failed. The following format is readable by machines and by humans. Rule of thumb: One event equals one log line. No comments in code When you want to use some method from the library and it doesn’t have a description — it’s a problem. { } List<User> public users (Bool limit, String group, String sort) // ... Guess games, anyone? The assumption is that it will return the list of users. But what is , and ? What are their values? What can be set there? limit group sort Without comments we need to read code to understand what is happening there. After reading open Pull Request with the following comment: { } /**
 * Return list of users.
 *
 * limit specifies to get users with limited access (default: true)
 * group user group to lookup (default: "regular")
 * sort  how to sort users (default: "asc"; possible values: "asc", "desc")
 * list of users
 */ @param @param @param @return List<User> public users (Boolean limit, String group, String sort) // ... Congratulations! You’ve got angry developers who spent a lot of time understanding code that they should not even know. is playing this game by . And another player is , who go with approach. Go making comments mandatory Rust documentation comments as tests Self-documenting code is a myth. Document your code. Users and the future self will be very grateful for such effort. Unpredictable responses For example, you want to get a list of prices set for some item in the shop during the specified day. API response might look following: { : , : , : [ , , ]
} "item" "78956745" "day" "2020-06-14" "prices" "8,72" "9,01" "8,02" What if there were no price changes during the day? Item ID and day are valid. The only thing missing is the list of prices. Consider the following options: 1) Prices are returned as an empty list: { : , : , : []
} "item" "78956745" "day" "2020-06-14" "prices" 2) Prices are not returned: { : , : ,
} "item" "78956745" "day" "2020-06-14" 3) Prices are set to null: { : , : , : } "item" "78956745" "day" "2020-06-14" "prices" null Two last options are not predictable. Option 2 modifies response by removing object from the response. Not good. Option 3 makes it worse. You saw that in response there is a list and now you observe different type. prices The best approach is to go with Option 1. You know that is a list. In future, you also expect that there will be a list. If there is no information, then return an empty list. Less confusion and meet expectations. prices Only once executed configuration properties You can give an option to the user to configure your service via configuration files or APIs. In some scenarios, this does make sense. But sometimes there is a case when configuration in a file is used only once to bootstrap an app. And then only the API is in use. Don’t do that. If you provide both options — both of them should work the same way. Do change in file — changes apply. Do changes via API — changes apply. Configuration operations that users do should be . idempotent It doesn’t matter how you set configuration — it should always work the same way. How to level-up DX It’s all about thinking. And thinking is something not easy to change. I would suggest to start with . It is a set of good practices to apply. It’s more oriented towards backend applications, but ideas can apply to other areas as well. Take a look at for inspiration. This is one of the companies that is known for great DX. Another company that I like and it inspires is . Also suggest to read fresh and nice article from Chris Coyer . Are you building CLI? Get inspiration from Carolyn Van Slyck talk on . The Twelve-Factor methodology Stripe Digital Ocean about meaning of DX for different people how to design Command-Line tools that people love And ask yourself questions: Who are end users / stakeholders? Is it another team? Other developers who perform integrations? How will this library be used? Can this be simplified? Is this readable and understandable? Does it look simple? Will my colleagues understand this? And ask for feedback to become even better. Hope you enjoyed it. Happy coding and nice mood!

We Need to Talk About DX (Developer Experience)

What is DX? Why does it matter? How can I do it well? What is DX? Developer Experience (DX) is the equivalent to User Experience (UX) when the user of the software or system is a developer. DX describes the experience developers have when they use your product, be it client libraries, SDKs, frameworks, open source code, tools, API, technology or service. DX shares some ideas and philosophies from UX design (or HCI), but builds on these with an eye towards modern technology and standards. Why does it matter? DX matters for the same reasons good UX matters. Users of your technology are happier, promote it more, and stay longer when the product has good DX. Happy developers are chatty developers, and when we talk to each other to recommend products, the ones with the best DX are at the top of the list. Follows is my list of best practices when it comes to DX. Do these, and you’re well on your way to success. The Guidelines Communication Good communication is key to a successful developer experience. The way you speak to developers is crucial to how they perceive you and your product. Tone: Be Authentic, Open and Honest The way you speak to developers is crucial to how they perceive you and your product. Developers can smell bullshit, and they don’t like fluff. If you be honest with developers, they’ll respect your product more. If you have a data breach, a bug, a period of downtime, or some data loss, be clear with this. Create a status page and comms system and use it to communicate with your developers. Be honest about your timelines and be prompt with any post-mortems or debriefs. Communicate product roadmap with product forums, and let developers contribute to those priorities directly. Engage with them, ask them what they think. Great Documentation Your docs are your voice to the customer. But what makes for great documentation? Always write your docs as if the developer is a beginner, not just with your technology (which they definitely are) but also the platform for that technology. If you’re documenting an NPM module, include a link to how to even install NPM in the first place, and how to include the code into other JS files. If it’s a ruby gem, the same thing. Consistency of language in the docs is also important. If you have multiple contributors to documentation, make sure they’re all using “function” instead of “method”, or “package” instead of “module”. This also is important for your own product related nouns, such as “Activity Log” instead of “Log”. Being consistent stops readers from becoming lost and second guessing what they’re reading. Thirdly, a logical layout and structure to your docs is important. Surface common reading, and lay out docs in order of integration steps. An “Overview” with core concepts then “Getting Started” section with installation and/or set up is a great start. What follows after that depends on your product, but you should know based on what you expect people to do — just document that expectation. Finally, verbosity is always great in docs. You can never say too much. It’ll be one sentence or a few extra words that really helps a stuck developer. It’ll mean the difference between a developer who feels comfortable and supported versus an irate one calling your support line. Docs can sometimes feel like a last minute thing, but slowing down, investing in them, will pay dividends in the long run. Good Release Notes and Changelogs When releasing a new version, it’s another important time to be on the ball with communications to developers. Explain clearly what is new, what was broken but now fixed (yes, own your mistakes, please), and what any risks of this version is (eg, this might break ). Even better if you can link to a public issue tracker for these for more detail. Why? Well, when developers want to catch up on versions, they want to be able to quickly scan the release notes or change logs and try find the thing they’re looking for. They might be asking “which version did this get deprecated in?” or “what version did x get added?” or “what version did they fix the bug I’m experiencing?”. If you can answer these in your release notes, then you’ve nailed it. Release notes are also a good place to point out any security vulnerabilities that have been fixed, which obviously add more motivation to update. Developers should always be motivated to update to the latest version. Having them on the latest version also reduces support overhead. x Respect Standards and Idioms When writing a client library, SDK, API, etc, it’s important to respect the standards of the industry and/or community and idioms of the platform from those gone before you. Respect Platform Idioms and Toolsets I work on an iOS SDK as part of my day job, and when I do this, I must always be mindful the app developer using this. What Xcode version are they on? What language are they using? Objective-C or Swift? How can I make this API work better with either of them? While just an anecdote, it’s important you also think of the same thing. So, think to yourself, what tools are people using to interact with me? What are they? Do they make a difference? versions Don’t Assume Programming Paradigms It’s easy to think that because you like a certain style of programming, others will like it too, but this isn’t always the case. For example, if you like functional programming, you may be tempted to write your library with a functional interface. Please don’t. Write it the plain, or more traditional or standard way, such as plain JS vs a Fluent Interface or plain Ruby or plain Swift vs a functional style API, or a Java Builder pattern vs just an object to construct, and then also provide a wrapper or for a given style. That way, everyone can use it, and no one has to learn a new style of programming just to use your code. If there is no given paradigm, chose what is best, preferably most likely to prevent mistakes and a quick time to learn. facade Consistency Consistency is key with interfaces for developers. Very much for the same reason as in UX, it stops people from making mistakes. Be consistent with the rest of the language or platform. For example, let’s say you have a simple library that talks to and endpoint and provides a native object for use. If you’re writing Java or C#, your asynchronous methods might expose a Listener pattern, which is very consistent with the language. However, if you’re writing Swift, you the equivalent method might expose a callback. If it’s in Javascript, it might also be callback, but it could be a Promise. Figure out what’s common on the platform by researching other code (with the ultimate source of truth being the platform source itself), and then use that. If it doesn’t matter, then be consistent between your different libraries across the different languages, but platform consistency comes first. Methods should be called similar names across the platforms, so developers integrating in multiple languages can gain momentum, and generally because it’s just cleaner. This goes back also to above, keep this in mind as you ship code for a certain language or platform. Respect Platform Idioms and Toolsets Be a Good Citizen For code that will be embedded in other people’s code (such as frameworks and libraries), it’s best to make sure your code isn’t going to be a cause of concern. If anything, this code needs to better than the code it’s in as it should never be an issue. Method Annotations and Docs If you’re exposing methods, try use annotations to indicate a few things. Some languages like Objective C and Swift provide these features, where as some tools like Android Annotations provide this. The first is nullability, can the thing you pass me here be null? What does that mean if it is? And can what the method returns also be null? With these explicitly called out, Developers can change their style to code more defensively or not around these cases. For as something as simple as adding an annotation, you may save your users a NullException or similar. Secondly, over-document. Document each parameter and method carefully, and name them well. Probably name them better you would your internal names, in an effort to make them accessible to beginners. The more documentation about how to use the method, any prerequisites or postrequisites it needs, and a hint to how it works, and any equivalents it has or redundancies, and any side-effects. Not only will this help external developers, it’s also great for your internal team to get up to speed if they’re making a change to the code. Well documented code is great. The usual rules of “don’t over comment” and “your code should be self-documenting” just don’t apply for external code. The more the better, always. It’s about reducing confusion and stopping that support line phone ringing. Method Removal and Deprecations If you want to change your mind about some external methods, you’ll need to slow down and let your developers adjust. The recommended approach for this is to introduce the new behaviour and deprecate the old. Deprecate refers to functions or classes that are in the process of being replaced by newer ones. What you must not do is just remove functions or change their behavior, as this will almost certainly affect other code that interacts with it. You should always deprecate the old first, an in a future, preferable version(more on this later) remove the deprecated methods. Deprecated periods should last at least a month, but can last up to a few years. major You’ve probably felt me defining deprecation above was a bit silly because you’ve seen and dealt with them before, well, it’s a great way to communicate and you’re used to it — so do it yourself when you’re the one providing the code. exactly — Non-Colliding Namespaces If your language that you’re programming with doesn’t have namespace or package support, then you should prefix your code to avoid this. This is fairly common in Objective-C, where a lot of provided classes have the NS- or UI- prefix. My code as SJ in front of it, for my name, or sometimes a acronym based on the name of the project. Using two or three letters (preferably three) reduces the risk of errors during compile time, where your code is named the same as something in the rest of code. If your language supports namespaces and/or packages, make sure these are also configured for the same reason. Threading Arguable more aimed at mobile development, be careful with threads and processes. Try use a secondary or background process to do your work such that actions such as UI work aren’t blocked by your code. Because of this, code with common multi-threaded pitfalls in mind, and test carefully. Be Open Source (At least try!) While I acknowledge that some code must stay closed source, if not required, have it be open source. Follow the , which, in themselves are part of a good DX. This advice is more of the same as above, centering around good communications. open source best practices Why Open Source? Open source code is more trusted by developers, and anecdotally, more developers are exclusively using only open source dependencies in their products. They’re able to look into the source and find and fix bugs, as well as inspect it for any code that is questionable, and remove it. Great Read Me What’s in a great Read Me? A , but in short, a good description, installation notes, good (trivial examples), contribution guidelines and any known issues. Links to more docs is also great. Some of the best projects I see also shout out top contributors, or shout out notable users of it. full list here is here Safe Space for Contributions Having a Code of Conduct for your open source efforts is super important. Your users could be anyone, and their contributions should be welcomed and protected no matter who they are. A code of conduct (even the one Github gives you by default) is great, as long as you action it if it is broken. Create a safe space for contributions, remember, these people are probably adding value to your company, why not do the best for them that you can? Open CI If possible, and if it makes sense to, open your CI system too. Most hosted CI systems are for open source projects, so just hook it up and tie it in. This will make it easier to contribute with pull requests and makes it easier for you to review and accept or reject contributions. Some would even recommend going further, and using bots. Use what you think you need. More active repos will need more automation to scale. free Make It Easy Make it easy for developers to actually get your product and integrate it. It’s amazing how many products would benefit from developers using it, but don’t understand how they think. Clear Pricing The first of these is clear pricing. No developer ever will ever click a “Book a demo” button. Let us have a free trial, or pop in our credit card and give it a spin. We want to know how the pricing works and what variables control how much it cost. Even better if that makes sense to us, eg things that would cause more costs for you, such as higher number of requests or more compute time used. Sure, value-based pricing is a thing, and you may want to work out a deal for larger customers, but if SpaceX can have a , so can your software product. freaking pricing page Self Serve Option As above, we want to be able to use it ourselves. We don’t necessarily want to sign a custom contract, have to get on a call with a sales person, or pay an implementation fee. We just want to sign up, integrate it that day and see if the price makes sense for the value we’re getting. Sure, your business may not work like that (and that’s okay), but that’s a compromise of the model, you miss out on a self-serve market. And as above, developers are a chatty bunch, and they might recommend your product to their friend who works for that customer you’ve always wanted, so you never know. But, of course, use your best judgement. Versioning Version your code and products correctly. Semantic Versioning is what the industry has landed on, and it’s good, and you should use it. In short, a version number should have three parts, three numbers. Eg, “X.Y.Z”, or “Major.Minor.Patch”. Patch releases fix bugs. Minor adds small features, and major removes deprecations and releases bigger features. So, when versioning, think carefully about what version number you are really meant to use, such that you communicate to developers the impact of the version. And sorry if you spent two weeks on a change, it might only still be only a patch version. The of the version number matters more. (SemVer) semantics Packaging Most languages now have one or more accepted way to distribute code. There’s NPM and Yarn for JS, RubyGems for Ruby, Nuget for C#, Maven for Java, CocoaPods/Carthage/SPM (grr) for iOS, PIP for Python… and the list goes on. Your code should be distributed by this way as well. As a developer scans your installation docs, they’re looking for the line that installs your product via one of these systems, they’re looking for gem ‘Sam’ or npm install sam in the first paragraph. Take the time to generate the files required to interact with these systems, and use Git Tags and SemVer to create and push releases to your users. Secondly, if the packaging system supports code signing or security features like that, be sure to use those, so your developers know the software came from you, and is less likely to be compromised. Do Your Best To finish off, we get onto the obvious stuff about the actual quality of your product. Use Your Own Stuff If you’re shipping anything that a developer will use, be sure to always test it as if you’re a new developer. Create a fresh project, integrate it and test it. Try to rule out any false positives from your dev environment and The more you do this, the more knowledgable you’ll be about the integration process, and that’ll lead to finding gaps in documentation, ReadMes and much more. Give this task to someone on your team completely unfamiliar with the product (or a friend if you’re solo) and see what they find confusing, and improve from there. really just eat your own dog food. Feature Set The feature set of your product must match what a developer has come to expect from competitors. However, you might have something they miss, and that might indicate a UX problem, or poor DX. Ask developers what is missing, and use that crucial (and free) feedback to make your product better. A good product also scales under load or is built for purpose well. It is also secure noting the latest concerns and keeps its dependencies up to date. So that’s what makes for great DX. In conclusion, a lot of DX is just doing what you’d expect if you were a developer. Put yourself in their shoes (and remove your knowledge of the subject) and try see what you’d expect, and do that. Have Fun Developers, like everyone like to have fun. Keep all your interactions light hearted and enjoyable for both sides. Remember: If they’re using your product, you’re on the same team. You’re just two people working together to solve a problem. Use your teamwork skills to make the interaction positive and enjoyable. Need help with this? Get in touch and I can help out you and/or your team. Liked this post? Please give me a clap or leave a comment to show your appreciation. It really keeps any person creating content on the internet going when you express your gratitude — we do this for you.

The Best Practices for a Great Developer Experience (DX)

Developer Experience (DX or DevEx) has become critical for us to drive innovation, productivity, and success. As software development teams vie for top talent and strive to deliver exceptional products, we find that DX is no longer a luxury—it's a necessity. There are telltale signs of subpar DX. It’s easy to miss or ignore them. I’m going to discuss the signs, and also share some of my ideas about how we can improve developer experience. Why Developer Experience (DX) Matters can make or break a development team. Developer Experience It's no longer enough to make incremental improvements to your development process. DX encompasses everything from the ease of use of your APIs and SDKs to the efficiency of your development workflows and the quality of your documentation. It’s usually a poor DX that is driving away your best people, or best opportunities to hire great people. It starts with looking after your engineers. But today, adopting tech to make engineers’ lives easier – including AI tools – will increasingly be a factor. And your best people represent your competitive edge. 7 signs of subpar developer experience As leaders, it's crucial that we recognize the early warning signs. These indicators can point to deeper issues that, if left unaddressed, may lead to unhappy developers, decreased productivity, and, ultimately, a negative impact on our product's success. 1.  Inefficient collaboration Communication bottlenecks and silos within development teams hinder progress. A lack of transparency and cross-functional collaboration means we waste resources in duplicated efforts, missed opportunities, and a slow development process. Be on the lookout for signs of miscommunication or confusion. 2. Limited tool integration The modern developer relies on various tools to get the job done. However, fragmented toolsets can create unnecessary challenges and a poor user experience when these tools don't play nicely together. Getting this wrong hampers developers’ productivity. Insufficient data synchronization and visibility can lead to information gaps, making it difficult for teams to collaborate effectively and make informed decisions. Watch out for developers complaining about the constant need to switch between tools or manually transfer data. 3. Slow feedback loops Timely feedback is crucial for continuous improvement, but slow feedback loops can stifle progress. If developers are left waiting for feedback or approvals, valuable time is wasted, and frustration builds. Keep an eye on your development process to ensure feedback is provided quickly and effectively. 4. Inadequate documentation and resources Comprehensive, accessible documentation is a vital component of a good DX. When resources for onboarding and troubleshooting are insufficient, developers waste time searching for answers or resorting to trial and error. Observe if developers frequently ask the same questions or express frustration when seeking information. 5. Insufficient support and community engagement Support channels and community engagement play an essential role in enhancing DX. Inadequate support and a disconnected developer community can leave our developers feeling isolated and undervalued. Look for frustration with support resources or a lack of engagement in company-wide initiatives. 6. Burnout and attrition This one’s a bit of a smoking gun. A poor DX can lead to developer burnout and high turnover rates. Overworked and underappreciated developers are more likely to seek opportunities elsewhere. That’s the start of a downward spiral of team morale and project failure. Keep track of team members' workloads and regularly check their well-being. 7. Low product quality and slow delivery When subpar DX plagues a development team, the consequences are often visible in the end product. Compromised product quality and delayed releases can result from developers struggling with inefficient processes and inadequate resources. Monitor your team's progress and product performance closely to detect signs of a subpar DX. How to improve DX: 4 Strategies and Solutions Recognizing the signs of a subpar Developer Experience (DX) is the first step. The real challenge lies in addressing these issues to create a better environment for your developers. 1. Seamless collaboration Collaboration can be painful. How much time do you and your project managers spend chasing updates on a feature? Or getting someone to review your pull request? Transparency is at the heart of a good foundation in collaboration. Foster a culture where conversation and collaboration happen in public channels, not in DMs. When it comes to tool integration, consider adopting a centralized platform that connects your core tools, such as Slack, Jira, and GitHub. This unified approach will reduce data silos, improve visibility, and enable more efficient workflows. This is exactly what our tool, , is built to do. CollabGPT CollabGPT isn’t just a dumb layer between your data and an LLM. It uses a complex architecture of AI agents to develop long-term “memory” of your projects and their context So, it can give you on-point summaries of what’s happened, actionable suggestions on what to do next, and answer any question about it instantly. 2. Improving resources and processes Ensure that your development team can access up-to-date resources and invest in creating easy-to-follow guides, tutorials, and FAQs. Encourage developers to contribute to documentation, as this will enhance the available resources and foster a sense of ownership and pride in their work. Consider adopting tools to help with this. allows you to manage and create documentation within the code editor. Swimm.io is an AI tool that analyses your code, extracts relevant information and presents it in a user-friendly way. Mintlify AI automates the process of writing code comments. Readable I wrote about more AI tools CTOs should know about for their software teams here. In addition to documentation, provide ample support through dedicated channels, such as help desks, forums, and mentorship programs. Engage with the developer community by organizing meetups, hackathons, and workshops to encourage knowledge sharing and networking. 3. Optimise the development environment Reducing friction in the development environment is critical to boosting productivity and satisfaction. Audit your existing tools and processes to identify areas of improvement and invest in solutions that enable a smooth, efficient workflow. This may include upgrading your development tools, refining your coding standards, or automating repetitive tasks. Ensure your development process includes timely feedback loops by establishing a robust review and approval system. Where possible, leverage AI-powered tools to analy e code changes, provide automated feedback, and help identify performance bottlenecks. z 4. And of course, culture Creating a supportive, inclusive team culture is essential to create a DX that makes great people stay at your business. Empower your developers by involving them in decision-making processes, recognizing their accomplishments, and providing opportunities for growth and learning. I’m a big believer that when you trust the right people to manage their own time, look after them and encourage them to establish a healthy work-life balance, everyone wins. Wrapping up Great developer experience and business success correlate. By identifying the signs of a subpar DX and taking the necessary steps to address them, you'll create an environment where your developers can reach their full potential. AI-powered tools and collaboration platforms for software engineering have arrived, and they’re ready to help you unlock enormous gains in your development process, streamlining workflows and offering valuable insights. Don't let subpar DX hold your team back—invest in the right strategies and solutions to fuel your organization's growth and success. Also published here.

7 Indicators of Poor Developer Experience and Ways to Improve It

An excellent developer experience correlates to great outcomes. Traditionally, improving developer experience (also known as DevEx or DX) has been an incremental project, and one that takes time and innovation. The good news? Artificial intelligence heralds the arrival of some much faster, more impactful ways to meaningfully improve DevEx. In this post, I will talk about four parts of life as a software engineer which are ripe for refreshment with the help of AI. I’ll cover how to improve DX with AI for software developers, and how this might look for teams like yours. ‍ 1. Code Delivery Software engineers at most software companies write code every day. But many engineers regularly have to complete relatively trivial tasks that keep them away from the more interesting problems. This isn’t usually popular – who wakes up every day to write test suites? Okay – some love it – but you see my point! So it seems the logical place to start improving developer experience. Fortunately, this is also the area I think has the most attention from AI innovators, with tools that work across a range of code editors from VS Code to Jetbrains, and across almost all programming languages including JavaScript, Java, Python, C#, Golang, SQL and many others. Autocomplete Let’s start with something already in the mainstream of software engineering. Autocomplete does what it says on the tin. It works the same way it does on your phone, but for code. Autocomplete for engineers is generally codebase-aware, so it understands your current context and coding patterns. It improves DevEx by making code easier and faster to write. is an established tool with an autocomplete feature. If you’re open to more cutting-edge tools, keep reading. Tools: GitHub Copilot This may be the least revolutionary implementation of AI for code delivery, but it has been around the longest, is better understood, and carries fewer risks. Great for the risk-averse organisation. My View: Understanding your codebase So, you've inherited a legacy codebase that's as tangled as a ball of yarn. Understanding and modifying the code is daunting. But AI-driven LLMs can come to your rescue. These models can analyse the code, answer your questions about its functionality, and suggest improvements. For example, you might ask the LLM, "What does this function do?" It could provide a concise summary or visually represent the code's logic. specialises in understanding your codebase and allowing you to ask any question to help you understand it. Tools: Adrenaline AI Tools that do this well are green, but improving constantly. Try for a free introduction to this concept with no set-up required. My view: Adrenaline Writing tests Whatever tests you’re writing, and whether you’re doing TDD or BDD, AI is capable of 10x-ing your output. Let’s face it. Most engineers aren’t thrilled at the prospect of writing test suites. AI can write suites of non-trivial (and trivial) test suites in seconds. What’s not to love? specialises in test-writing Tools: Codium Specialised tools appear to do a better job of test generation than simply asking ChatGPT, because that’s what they’re trained for. Invest in the right tools. Your devs will thank you. My view: Intelligent code assistance This is the “next level up”. Intelligent code assistance systems aim to have total comprehension of your codebase and context, and can write, refactor or test code. In practice, that means that AI can suggest substantial snippets of code, detect and fix errors, recommend best practices based on your project’s specific context and more. Pretty powerful. Depending on your tool, you may be able to ask questions or interact with the codebase through natural language processing (NLP), in the same way that you might talk to ChatGPT. This is a home run for teams who want to have good developer experience – a type of tool so good that going back to the old ways doesn’t feel like an option. This post is about DevEx, but it’s straightforward that these leads should lead to far better outcomes across the board. Tools: is an established AI code assistant. It benefits from being legally robust and compliance-friendly, but runs on the now-outdated GPT-3 at the time of writing. Tabnine isn’t out yet, but it will be able to do many things, including explaining code, fixing errors, testing, writing pull request templates and more. GitHub Copilot X is currently in Beta if you can’t wait for Copilot X. They can look at your code graphs and company docs alongside your codebase for richer context. Sourcegraph Cody Mutable AI is a slimmer version with features like autocomplete, refactoring, and prompt-driven development safely out of Beta. GitHub Copilot X is the most hyped tool in this category, and it isn’t even out yet. Organisations with a greater appetite for risk may be able to use “greener” AI and significantly speed up development and gain a lasting competitive advantage. Tabnine has been loved by many organisations since 2018, and I would guess that they are working to roll out on GPT-4. Watch this space. My view: 2. Writing Documentation and Comments Documentation is the lifeblood of any software project, providing essential guidance and information for developers, technical managers, and product managers alike. However, creating and maintaining accurate, up-to-date, and easily digestible documentation can be daunting. You hate bad documentation, and so do your engineers. And frankly, most of them aren’t enjoying writing it either. AI-driven documentation and comment generation are ready, and you should never have incomplete, outdated or confusing docs again. By harnessing the power of AI, we can automate the process of generating comprehensive and context-aware documentation. Tools: analyses the code structure, extracts relevant information, and presents it in a user-friendly format. Mintlify Readable AI automates the process of writing code comments. If it’s left to humans (no matter how well-meaning), docs will never be a priority. Give the job to a tool that can do it in seconds, consistently, and that won’t hate writing them. My view: 3. Collaboration Tools You and your engineers are probably sinking hours every day into keeping up with developments in their projects. Let’s think of some examples of places that drain time: Catching up with Slack and Teams Searching for where someone shared a link you need Chasing someone to review your pull request Checking for new commits Trying to work out whether you’re unblocked yet by checking Jira If each person spends 2 hours every day doing this, and you have ten people on your team, that’s 100 hours every week. As projects grow in size and complexity, the time it takes to catch up and find what you need compounds, leading to miscommunication, duplicated efforts, delays and so on. This is the kind of frustration that engineers complain to their friends and family about at the end of the day, the kind of annoyance that loosens company loyalty. That’s not something most teams can afford. AI-powered collaboration tools can help teams overcome these challenges and streamline their workflows. Collaboration Assistants Numerous organisations are rushing to add AI to their own platforms. The idea is this: instead of trawling through messages and threads looking for the salient points, AI will pick it out for you. Doing this without AI is a massive drain of time. While there are collaboration bots out there (many of which are specialised to one platform, like Slack), none are yet specialised in software engineering. What I mean specifically is that they don’t integrate with the likes of GitHub and Jira, and aren’t able to surface things engineers care about, like pull requests. My view: 4. Code Review By analysing the submitted code and providing intelligent recommendations, AI can assist developers in identifying potential issues, adhering to coding standards, and understanding complex code snippets. This reduces the time spent on code reviews and minimises the risk of human error. For senior technical managers, this means a more efficient and accurate review process, resulting in better code quality and maintainability. Tools: Codeball AI evaluates pull requests, highlights risks and can automatically approve low-risk pull requests. Planar does something similar What The Diff can create pull request summaries and manage instant code refactoring, to avoid the back-and-forth. Truth is, code reviews can be slow, arduous and a reliable blocker to progress. Some code review tools claim to be able to 10x your code review process. Even if they can only 2x it, they’re often well worth the investment for DX alone. My view: We wrote this blog about the best tools that CTOs should know about. Wrapping up AI can transform the developer experience by streamlining code delivery, enhancing documentation, optimising collaboration tools and more. By leveraging the power of the underlying neural networks, deep learning, machine learning algorithms that sit under AI, your team can enjoy a more efficient, engaging, and enjoyable work environment, leading to better outcomes across the board. Done right, you’ll get the most out of your great developers and have happier people, better developer productivity and better development processes. Your developers, technical managers, and product managers will thank you for making their work lives more satisfying and productive. Don't miss out on more insights and thought leadership in the world of software engineering and AI. Also published . here Featured image generated using Kadinsky 2 with the following prompt: An engineer looking through a pair of binoculars.

Improving Developer Experience with AI

Collaboration in software development calls for many people to come together to create a product. And to increase productivity and improve the overall throughput, the productivity of every individual within the team matters. But what exactly is developer productivity and how to measure one’s productivity in an ? SDLC Demystifying Developer Productivity Productivity in general aims to eliminate all the plausible distractions and interruptions that can stop a person from putting in their best efforts. The same principle applies to developers as well. Although the concept itself is scalar in nature and not measurable in one fixed way, teams of many organizations have come up with standard guidelines and metrics in recent times that can act as a baseline while evaluating a developer’s productivity. A developer’s productivity was traditionally determined by the number of lines or features a developer could create in a given timeframe. While this did serve the purpose to some extent, it didn’t take into account the quality or the number of re-runs required to deem the code fit for the product. To better gauge productivity metrics like code quality and tracking task completion are incorporated. A developer or a dev team can be complemented with dev tools that would have a direct impact on productivity levels. Let us look at some practices that could maximize a developer’s performance. Best Practices to Improve Developer Productivity DX or Developer Experience Source Developer experience is directly proportional to developer productivity. Developers should be given the freedom and power to write great code. Anything that reduces repetitive efforts or improves the development environment boosts developer productivity. This can include using better dev tools like IDEs with features like auto-suggestion, auto-formatting, advanced debugging options, etc (or) using Backstage to improve the development lifecycle and onboard new developers. , originally developed by Spotify, is a platform used to build developer portals. At the center of Backstage is a software catalog that can be used to create software templates. These templates serve as a piece of information about the infrastructure, tooling, troubleshooting, and software components, and also establish relations with other components. Backstage This ability to abstract away a lot of the operational, CI/CD, and infrastructure knowledge required to run an application or product is one of its key benefits. Additionally, it can lay the groundwork for your developer experience by serving as a primary information hub for the services offered by your business. A good developer experience is certain to fuel productivity and improve output, as a happy developer ships great code. Developer Portal Developer portals aggregate information related to the exposed that can be used by other developers to build something on top of the exposed APIs and SDKs. APIs and SDKs The developer portal seeks to produce more tasks faster than a single team of developers working without assistance from the community. A developer portal also aids teams in uniting in order to end ineffective collaboration. So, and how can it improve developer productivity? why is a developer portal important Simply put, a dev portal structures the documentation so it may be navigated through and accessed as per the developer’s needs. For someone who’s new to the documentation, for example, it is important to segregate and show content that first explains the product and its working and then goes on to explain the functional implementation and not the other way round. A poorly formatted developer portal might confuse the developer, requiring them to invest more of their time in properly understanding the flow, thereby making the whole process tedious. A developer portal is not just about documentation, it also facilitates smoother onboarding for new developers by grouping relevant information and tools together. Jot Down the Requirements It is one of the simplest yet most effective ways of solving a problem. Oftentimes, developers with the intention of implementing an efficient solution, end up deviating from the original problem and solving some other problem that may not even exist in the first place. “If you can write down the problem clearly, it is half solved.” The first step of solving a problem is to ideate solutions keeping the problem centerstage. The problem statement gives insight into the requirements, which helps us decide on the project infrastructure. Consider the below problem statement. Develop an application for a B2B client, i.e., the end goal is to develop a web application for a business to track and analyze its sales. Once the problem statement is available, one should thoroughly analyze the statement and extract all the requirements. From the above statement, the following questions arise. Q: Since the client wants to analyze their company’s performance via a dashboard, should SEO be given importance? A: Since the application is mainly based on an internal dashboard that can only be accessed by authenticated users, there is no way web crawlers can fetch relevant information from a dashboard and rank the site in search results. So, SEO need not be favored in this scenario. Q: The results are generated in real-time. So, should the application be statically generated or dynamically rendered? A: The results would typically be displayed as charts, tables, and grids in real-time, which requires fetching and updating data frequently. Statically generated sites are good when the content is barely or never updated. Thus, in this case, the data needs to be fetched and rendered dynamically. Q: The application can be accessed via a desktop and a smartphone. Should the site be responsive? A: Although such dashboards and analysis are typically done on a desktop, the user might use tablets too. When using tablets, responsiveness comes into play when in portrait orientation. So, regardless of how the end users access the site, edge cases should always be taken care of. With each question, the problem can be further divided until a straightforward answer can be obtained. What we did above was simply break down the problem statement into smaller problems and answer each of them separately. These answers help us decide the tech stack, infra, interface, and everything else. Conclusion Productivity can be improved in many ways and it differs from person to person. The important thing is to identify the areas where you feel you can improve and work on those. These were some of the ways in which you can improve developer productivity. There are many other ways as well. For example, you can use a task management tool like Jira to track the progress of your work and also get visibility into the work being done by other members of your team. You can also use a code review tool like Gerrit to improve the quality of your code and also ensure that only well-tested and reviewed code makes it into production. Improving developer productivity is an ongoing process and you should always be on the lookout for new ways to improve it. What works for one might not work for another. The key is to experiment and find out what suits you the best. Moreover, do not forget to take breaks in between and keep yourself hydrated at all times!

What is Developer Productivity? Basics and Best Practices

There are many projects, products, and services to choose from when making decisions about the tools you and your team use. One of the aspects many of us look at to help assess if a tool is useful to us is , but how do you judge what good documentation is? the documentation A tool might offer exciting features, yet, the of the documentation might be lacking. When evaluating a new tool, the developer experience matters as much as the offered features. developer experience This post aims to help you identify key factors to look for, how that might reflect on the project, and how well it will meet your expectations. Onboarding and Getting Started If you are learning about a new tool, then the getting started guide for any project is typically the first document you read. A bad experience is likely to put any casual reader off of investigating further. First impressions matter, so below are four factors to look for when evaluating the getting started experience for documentation. Self-serve option available Trying the time-honored “getting started" guide is typically the first point of call for developers assessing a new technical tool. There are some tools (especially in the SaaS world) that rely on onboarding you through a front end first and taking you through the first steps from there instead. In either case, prioritize tools that allow you to create an account and test yourself without the need to make an appointment with a sales representative or fill in excessive forms. There might be some valid reasons for doing this, such as a private beta or that the project is new. But often, it’s purely to force you through a sales process and bombard you with sales messages. This isn’t directly related to documentation, but often you also can’t view documentation until you are through this process, which makes it hard to evaluate at all. Time to get started If you evaluate multiple options, then how long it takes you to follow a getting started guide from the beginning to a satisfactory conclusion is one measure to measure by. While the real-time can depend a lot on the tutorial’s complexity, for comparable tools or guides, a shorter time is a good sign that the team has spent time reducing barriers, testing steps, and checking that the language they used is clear. Real-world examples "Getting started" guides tend to focus on simplicity and speed. Often this is intentional to make a tool appear “easy” to use. However, if the examples and steps the guide follows are unrealistic for any “real world” use case for the tool, then is it a good getting started guide? Dependencies and Prerequisites Certain programming languages are notorious for having deep and complex dependency trees. This means that a project might leverage code from a 3rd party (which is common), but then that tool also has its dependencies. Following a getting started guide should not have to take you down a complex path of conflicting dependency versions or surprising undocumented prerequisites you have to figure out. This can show that the developers or writers of the documentation have not tested examples from scratch on a “vanilla” new user set up. Ideally, a project should work with the most popular or most supported (and , for example) versions of languages and operating systems. If they don’t, it can show a lack of meaningful commitment to development or specific platforms. LTS At the least, the documentation should state which versions you need and a rough idea of when to expect support for newer or more popular versions. Continuing the journey A great getting started guide is a big plus for any project you are evaluating, but rarely does a getting started guide help you apply anything to a real-world production application. One of the hardest parts of creating documentation is taking a reader on this crucial journey, and it’s generally where most people get frustrated with documentation. Some projects have a much clearer and defined use case than others (for example, a payment API versus a CMS), but there are some general things to look for. A good getting started guide should suggest common pages or paths for you to follow next. These could be generic, such as key components of the tool, finding further information on a feature, or following typical use cases based on user research. It’s near impossible for documentation to suit every possible use you might have, but it can help you assemble the knowledge you need. Code examples Not wanting to disappoint anyone reading this who writes documentation, but it’s an adage that developers often don’t read the documentation thoroughly but rather scan for code examples. is structured to ensure that important text surrounds code examples, so there is more chance you notice it. Good documentation Code examples are often a source of annoyance for anyone reading documentation, and I’m sure you have come across one that is incomplete or doesn’t work. There are different types of code examples, and in each case, their purpose should be clear. Some code examples are part of a tutorial or guide, and we expect the reader to follow them in order and build a full piece of code that works as expected. In these cases, the examples should tell you all you need to know and not leave anything to assumption to result in a working example. Some code examples are illustrative to show a concept or implementation detail, which means they do not work without replacing placeholder values or extra code. Documentation should make these clear and suggest what you need to do to make them usable. While not always necessary, documentation should explain or show you the expected output for code examples, so you know that you have implemented it successfully. Finally, if a project supports multiple programming languages or implementation options, then the documentation should show code examples for all of these. However, this is a lot of work, but examples for the most widely used options are essential, and guidance on using the other supported options enough. Reference - SDK and API documentation Filling in the documentation gaps is generally the role of reference documentation, which includes , architecture explanations, and other aspects of the project readers might find useful to know if they need to. API endpoint and function documentation Firstly, is reference documentation available, or do you need to dig through the codebase to find it? If it does exist, how complete or useful is it? Often teams autogenerate reference documentation, and that’s fine, but often descriptions come from code comments, and code comments are not always useful to a reader. Reference documentation can be more abstract than other documentation as it describes individual pieces of a project instead of how to use them. However, good reference documentation still explains what that piece is and how it works. The is a common example of useful and usable autogenerated (but using highly customized tooling) API documentation. Not wanting to publicly shame any project, this tweet from Ricardo Ferreira sums up the problem with documentation generated from comments perfectly. Stripe API documentation Language Good language is a big topic, and it doesn’t necessarily affect the quality of a project. It can show that the team behind it goes the extra mile to care, which is a good sign. Acceptable documentation should be free of spelling mistakes and other typographical errors. Excellent documentation should use a consistent voice, terminology, and style. What constitutes “correct” in these cases is personal and opinionated, but consistency is key. There are a handful of popular and commonly used style guides, such as the and style guides. Whether that documentation follows one of these style guides over another, or its own custom style guide is not what’s important. However, if a company follows a style guide, it shows they have given that extra thought and care to their documentation. Google Microsoft Bonus points These discussion points don’t quite fit into any of the sections above but show that a team has an extra eye for detail. How does the documentation look? Something that looks fantastic and uses the latest tricks in web development may not equal useful and useable documentation, but if it’s both of those, then even better. How often is the documentation updated? There are some good reasons for not updating documentation regularly, such as an older project or problem-free documentation, but it can also indicate a dormant project that’s best avoided. Good documentation shows a team cares We all know that documentation is hard, especially for solo developers or smaller teams who also need to focus on features and bug fixes. However, when there are many options to choose from when evaluating new tools, frameworks, and services, and sometimes weighing them up on features alone is inconclusive. Therefore, the documentation’s developer experience matters. Good developer experience and documentation indicate how much a team and community involved with a project care about their users. More importantly, it indicates how much work could be involved in implementing projects you are evaluating. If tutorials are poorly written, or don’t make sense. If code examples don’t work, or important details are lacking. Will you find similar problems and a lack of concern in a project after investing your time and business in it? Previously published at https://humanitec.com/blog/developer-experience-documentation

How To Define The Good Documentation Skills

No one enjoys receiving errors messages when working with computers, but there is something worse: . Can it get even worse? Yes: . software that fails silently software that proceeds with the wrong data or assumption But let’s stay positive: if errors are not all that bad, what are the characteristics of good errors? 3 questions for every error A good error is actually very helpful and can potentially prevent disastrous and expensive consequences. An error message is a medium and as beautifully elaborated by this TED talk, it should start with . communication why A good error message should indicate: Context about the goal of the process being executed and why it is an error WHY it went wrong and the computer can’t proceed? A map for finding the root cause and inspecting more. Stack trace, error code or even a state dump HOW the error was detected? Suggestions for recovering or taking an alternative path to the goal. WHAT can be done to resolve it? Error consumer If the error is supposed to be consumed by someone other than the end user (support, developers, auditors), there’s typically an online or offline logging system in place. An : gathers the information on the user’s system without transmitting it to the consumers . The most common forms of offline logs are or . In this case the user is offered with choices for how to transmit the error (usually an optional step). offline log memory dump, stack traces log files An : gathers the information on a remote server. All you need to give to the user is a unique id that can be used to put together an error report for what they were doing. online log In this case the error should also answer: **WHAT does the end user need to do?**Steps to send the unique error id or offline log for further investigation and support Usually in form of timestamps WHEN did the error happen? Usually some form of identification like user id, session id or even name. This data might be subjected to GDPR regulation, see my other article on the matter: WHO was trying to achieve the goal? GDPR terminology in plain English GDPR pseudonymization techniques Examples of bad errors Too many systems fail to give a good error which leads to user frustration. Windows Blue Screen of Death (even has its own acronym BSOD) is probably one of the most cursed error messages: For an operating system that is developed for non-technical end users, it has embarrassingly too little information. It fails to answer WHY, briefly touches briefly on WHAT and jumps to WHERE the error happened. The instruction for HOW to solve the error is generic and not very specific (because the WHY is often unknown). 2 decades later, Windows shows even less information and expects the user to pull out their phone and scan a QR code: Examples of good errors The web platform is much more flexible and leaves room for creativity with powerful tools. 404 (page not found) is a classic error on the browsers. While some sites just throw the error number at the user and expect them to figure out the rest, Hootsuit has an actionable button: go to the main page: Can it be done better? Of course. List24 don’t leave you there, it suggests you to search and even offers you some alternative content to click on right away: While some like Path show empathy: Chrome totally distracts the users by offering them a game when it can’t connect to the internet: Conclusion Software developers usually treat the errors as the ugly part of their code. That is because they are mostly aiming for the where everything works and they solve the problem that the software has promised. However, when the end user is trying the software, they experience the which is different from the in many ways: happy scenario real scenario happy scenario They use real data for real activities (as opposed to test data and activities) WHAT? When they fail, they feel more frustrated because they don’t have the source code ready to be tweaked and fix the problem HOW? They often don’t have enough context for what went wrong (hence the cliche of cursing the “computers”) WHY? Good software is a pleasure to use. It not only prevents errors, but when it fails, it gives actionable error messages that help the user understand why it went wrong, how the error was detected and what can be done to solve it. If there’s one key take away from this article, I want it to be: Errors are encountered by real users with real goals. The error message is a communication method to help the user continue their goal. ⚡_️_Liked what you read? Follow me to be notified when I write something new.

What makes a good error message?

Developer Experience (also called “DevEx” or “DX”) has a direct positive correlation with productivity and innovation. Elsewhere, I wrote about how to spot the telltale signs of subpar developer experience. If you want to, you can read that one here. In that post, I suggested . It’s all about doing things that eliminate irritations and frustrations and maximize joy. These were: four ways to improve the developer experience Invest in resources and processes that make life easier, and nurture a sense of ownership. Work toward seamless collaboration to reduce data silos, improve visibility and enable more efficient workflows. Optimize the development environment to reduce friction and automate repetitive tasks. Be conscious about culture to create a supportive, inclusive environment where people feel trusted and appreciated. AI is ready to solve some major DX problems. Teams that get this right can expect to unlock substantial competitive advantages. I want to share how I think that can work. AI for Avoiding Data Silos and Enabling Visibility This category of tools is all about exposing high-quality information in the right places. That’s everything from creating useful, accurate resources to ensuring the right information reaches the right people at the right time. For Creating Resources The first use case for AI is perhaps one of the more obvious use cases – generative AI for creating resources. These kinds of AI can do things like write code documentation for you automatically or summarize meetings so you don’t have to rewatch the whole thing. Pick 1: Meeting summarization with . Otter AI automatically summarizes meetings and captures slides to generate easy-to-digest summaries of meetings. You can connect it to your Google or Microsoft calendar, and it can automatically join and record your meetings on Zoom, Microsoft Teams, and Google Meet. Otter AI Pick 2: for automatic documentation. Almost nobody is buzzing to write docs for their code, so make the most of code-aware LLMs and get them to do it for you. Mintlify For Surfacing What Matters The second use case for AI in this category is for surfacing what matters. As far as I’m aware, there’s only one tool that observes and reflects on everything that happens across the tools you use and surfaces what matters in a bespoke, personalized way. It’s called Stepsize AI, and I’m building it with my team at Stepsize. Pick 3: for surfacing what matters. You can schedule recurring reports bespoke to any team or person. Replace the daily standup, send recurring team updates, request personalized alerts when something you care about happens, or generate ad-hoc reports ahead of meetings. Stepsize AI It deeply understands the context of what your projects and goals are and can even answer questions about what’s happening. Here’s what that looks like: AI for the Development Environment We have to invest in reducing friction in the development environment if we want to boost productivity and satisfaction. AI has come on leaps and bounds in the last year in developing specific niches of the engineering process. For a more extensive list of dev tools CTOs should know about, head here. For Code Implementation Ask any developer, and they'll tell you - coding is often the stage where ideas take form but also where major bottlenecks occur. Too often, teams lose precious hours to syntax errors, library issues, and bugs that just won't squash. This hurdle can feel like a steep climb, causing unnecessary delays and frustration. Furthermore, codebases are living, evolving organisms. Your team's work isn't just about implementing new features, but also about understanding and navigating existing code. Annotating and understanding complex codebases can be a Herculean task, especially if the original author isn't around. AI Pick 4: for code implementation. It offers what feels like the next generation to GitHub Copilot, with code completion, error detection, and more that make each part of the software development process from reading, understanding, and writing code much more efficient. Sourcegraph Cody Honorable mentions: for writing tests, for an established but slightly less-cutting edge tool. Codium AI Tabnine For Code Reviews It's often a time sink because it's easy to get lost in endless lines of code, particularly if you're working on a complex project or a large team. Moreover, non-technical team members often find themselves left out of the loop. When your developers, product managers, and stakeholders aren't on the same page, it can cause confusion and delay decisions. AI Pick 5: to improve code reviews. To optimize the review process, What The Diff is worth your time. It’s an AI assistant designed to provide summaries, review pull requests, and even refactor code, making the entire review process more inclusive and efficient. What the Diff It’s also great for keeping non-technical team members in the loop and works really well with tools like (above) because it helps surface what matters about each pull request. CollabGPT Honorable mention: does something somewhat similar but with a focus on a great code review experience. Planar Deployment and Maintenance Let me guess. Nobody on your team lives for maintenance. But you have to deal with dependencies and migrate code. there were a way to do that hands-free. If only AI Pick 6: for hands-free tech debt management. Right on cue! Grit helps manage code migrations and dependencies, and its radar is designed to spot potential regressions, offering a smoother ride through the deployment and maintenance stage. Grit.io What You Need to Remember… AI for software developers isn't a silver bullet that's going to solve all your DX issues with DX tools overnight. It's a facilitator. It’s about leveraging the power of artificial intelligence to bolster the creative and innovative elements of software development. That's where the real competitive advantage lies. Adapting to an AI-driven Developer Experience (DX) requires more than just selecting the right tools. It's a holistic process that impacts your team's workflows, skillsets, and overall development culture. As leaders, our roles in this transition extend beyond decision-making to driving the necessary change. Firstly, ensure your engineering team is trained and well-equipped to work with AI tools. Next, reevaluate your development workflows. Lastly, and perhaps most importantly, nurture that culture of continuous learning and innovation. The AI landscape is continuously evolving, and to make the most of it, your team should too. Encourage your software engineering teams to stay updated with the latest AI trends, offer regular training, and create a safe space for experimentation. Remember, AI's potential is best unlocked when human creativity and machine intelligence are blended. That’s why I created Stepsize AI, the AI Operational Intelligence Engine that takes all the manual work out of keeping informed about what matters. By integrating with Jira, Slack, GitHub, and more, Stepsize AI deeply understands the context of your projects and goals, providing bespoke, personalized updates for any person or team depending on what matters to them. We believe Stepsize AI is a game-changer. I’d love for you to give it a spin. . Try out Stepsize AI here Also published here

Leveraging AI to Enhance the Developer Experience (DX): A Guide

*SCHWARZENBACH, Switzerland, May 3rd, 2023/Chainwire/--*DX25 Labs has officially launched the public testnet for its powerful new decentralized exchange (DEX) built on the MultiversX blockchain ecosystem. The platform is aimed at both individual and institutional traders in the MultiversX ecosystem. set to introduce a robust set of DeFi tools After announcing that had raised $750k in seed funding in early March, it has officially , which will offer users the opportunity to try out some of the features the platform offers. DX25 Labs launched its public testnet The company aims to bridge the divide between TradFi and DeFi with a comprehensive suite of - novice and professional traders in the MultiversX ecosystem. products tailored to both sides of the aisle “Over the last few months, our team has worked tirelessly on preparing DX25 for launch. The public test net will give users a glimpse into what we have planned for the platform as we prepare to launch a comprehensive suite of trading features throughout the course of 2023 and beyond. We’ve set out to build a powerful new trading platform for the MultiversX ecosystem that offers a robust set of features without overcomplicating the overall user experience,” said James Davies, Chief Product Officer of DX25 Labs. DX25 was developed by Tacans Labs, the DeFi builder arm of Switzerland-based Tacans AG, with a team of over 40 staff dedicated to developing and marketing the platform. The public testnet will offer users the ability to try out some of its features, such as swapping and the creation of liquidity pools that make use of its concentrated liquidity and multiple fee levels. Together with the launch of its public testnet, the company has aimed at incentivizing early users of the public testnet. announced a rewards program DX25 has allocated a total of 100,000 USD worth of $DX25 tokens for its rewards program, which will require users to use and promote the platform actively. ‍About DX25 Labs ‍DX25 is a feature-rich decentralized trading platform built on the carbon-neutral MultiversX blockchain. Its combination of DeFi and TradFi features sets it apart in a sea of similar DEXes. The leadership team includes award-winning entrepreneur Mathias Lundoe Nielsen, and industry veterans, James Davies, Ivan Ivaschenko, and Marie Tatibouet. For more information, visit www.dx25.com ‍About Tacans Labs‍ Co-founded by Danish entrepreneurs Lars Seier Christensen, founder of Saxo Bank and Concordium blockchain, and Mathias Lundoe Nielsen, an award-winning serial entrepreneur with multiple tech ventures, Tacans Labs is the DeFi arm of Tacans, a web3 venture builder invested in the future economy of blockchain by building, funding and acquiring cutting-edge Web3 companies. Started in 2021, the group’s portfolio comprises of seven Web3 companies across multiple sectors with a combined valuation of $63M+. For more information, please visit www.tacans.com Contact PR Manager Dion Guillaume Tacans Labs dion.guillaume@tacanslabs.com 0734545400 *: This story was distributed as a release by Chain Wire under HackerNoon’s Brand As An Author Program. Learn more about the program .* Disclaimer here

Public Testnet Announcement: DX25 Launches DEX on MultiversX Blockchain 

With digital transformation and the move to online operations, companies are increasingly relying on Salesforce to manage many of their operations.  In this context, teams are turning to Salesforce CI/CD to automate manual workflows, which help them handle these growing workloads and quickly deliver quality work to their end-users. This article gives you a short overview of how to implement CI/CD in Salesforce DX. Components of CI/CD A development process that uses version control as the source for new development activity is used to build Salesforce CI/CD . The way you manage and coordinate concurrent work streams and multiple environments are then determined by the Git branching strategy you choose. Automation is used in this process to validate deployment packages, run tests, and move work items along the pipeline. Individual CI jobs can be set up using a solution such as AutoRABIT, Gearset or a standard automation tool such as Jenkins. The continuous integration in DevOps processes runs on a regular basis or is triggered when branches in Git merge, and they can conduct tests before deployments across version control and Salesforce environments. Salesforce DevOps Implementation of CI/CD with Salesforce DX Implementation of the Salesforce CI/CD pipeline is separated into four stages: Source Build Test Deployment Before proceeding to the next stage, each succeeding stage must be accomplished. All steps are constantly checked for faults or anomalies, and feedback is sent to the delivery team. Each development, whether a bug patch or a feature enhancement, is routed via the CI/CD pipeline in DevOps before being deployed to production. Source It is the first stage of Salesforce CI/CD workflow. Here the CI/CD pipeline in DevOps will be activated by any change in the program or a predefined flag in the code repository. This level is all about source control, including version control and change tracking. When the automated process detects a change in the central repository (commit, new version), it will start tasks like code compilation and unit testing. Build This stage of the pipeline converts the source code and all of its dependencies into an executable/runnable instance of the development. This stage addresses software builds as well as other types of buildable objects such as Docker containers. Failure in this build could suggest a fundamental problem with the underlying code. A centralized artifact repository such as yarn, JFrog, or a cloud-based solution such as Azure Artifacts can be used to centralize the storage process of building artifacts. If there are any issues with the current build, we will be able to roll back to the previous build. Test The test stage includes all automated testing to validate the software's behavior. This stage's purpose is to keep software defects from reaching end users. This stage might include a variety of methods of testing, ranging from integration testing to functional testing. This stage will also reveal any flaws in the product. Deploy This is the Salesforce CI/CD pipeline's final stage. The package is now ready to be deployed after passing all of the preceding phases. At this point, the package is deployed to appropriate environments, first to a staging environment for additional quality assurance (QA) and then to a production environment. Infrastructure provisioning, configuration, and containerization utilizing technologies such as Terraform, Puppet, Docker, and Kubernetes can all be part of the deployment stage. Conclusion New business needs and opportunities constantly increase the workload of Salesforce teams. So, teams are turning to Salesforce CI/CD to automate manual workflows, which help them handle these growing workloads and quickly deliver quality work to their end-users

CI/CD Best Practices for Salesforce DX

The Joget team is proud to announce that the first preview release for is now available for download! Joget DX What is Joget DX? is a next generation open source application platform for faster, simpler digital transformation (DX). Joget DX combines the best of , and in a simple, flexible and open platform. With Joget DX business and technical teams can collaborate to rapidly build full-fledged enterprise applications visually, anywhere, anytime. Joget DX business process automation workflow management low code application development Joget started as the open source in 2009. Initially a workflow engine for business process automation, Joget evolved into a full-fledged application development platform in its third major release Joget Workflow v3 in 2011, back before the term “low code” was even coined by Forrester in 2014. Joget Workflow project on SourceForge With almost 200,000 open source downloads and more than 10,000 community members since inception, the latest major release was introduced in 2018 with focus on modern User Experience (UX), and App Maintainability and Performance. Joget DX is the next generation successor to Joget Workflow. From Workflow to Digital Transformation (DX), the product name change reflects the complete digital transformation capabilities offered by the platform. Joget Workflow v6 What’s New in Joget DX? Joget DX emphasizes the following key focus areas: User Experience (UX) and Progressive Web Apps (PWA) DevOps and Application Performance Management (APM) Artificial Intelligence (AI) and Smart Decisions User Experience (UX) and Progressive Web Apps (PWA) Enhanced User Experience for Desktop and Mobile Joget DX includes a new default Progressive theme for apps inspired by Google’s Material Design to promote beautiful design and good UX. The admin and app designer interface has also been enhanced for greater usability and intuitiveness. Progressive Web App (PWA) Support is the future of mobile apps and the web, pushed by heavyweights in the industry especially Google. Joget DX apps automatically incorporate PWA features so that all apps will be PWA baseline compliant without requiring additional steps. Progressive Web Apps (PWA) Web Push Notification and Offline Support With features such as adding to home screen, offline support, push notifications and more, PWA compliant Joget apps offer a user experience approaching that of a native mobile app. DevOps and Application Performance Management (APM) Built-in Application Performance Management Joget DX incorporates built-in features that automatically monitors system and application performance. The monitoring is done at runtime, and alerts can be configured for various metrics including errors, so that email notifications are sent when thresholds are exceeded. application performance management (APM) Web App Log Viewer Monitoring of logs is still an important way of finding and viewing errors, and Joget DX provides real-time streaming of logs in the web console for easier viewing and accessibility. Embedded Git Integration for Collaborative Development and Deployment Git is the most popular free and open source version control system today. Joget DX provides automatic integration with Git behind the scenes. All app definitions and components are stored in the filesystem and version controlled using Git, so apps can be collaboratively built by multiple users or teams. Deployments can be automated or performed manually using standard Git commands, and also integrated with continuous integration and continuous delivery (CI/CD) pipelines. Artificial Intelligence (AI) and Smart Decisions Plugins for Process Decisions Decision making is one of the most important aspects in any business. As a part of process automation, Joget DX provides support for Decision plugins that can be mapped to process routes for decision making. Bundled No Code TensorFlow AI Plugin TensorFlow is the leading open source library for machine learning. The AI focus in Joget DX is to simplify the integration of pre-trained AI models into end user applications. The bundled TensorFlow AI plugin provides a no-code approach to uploading and executing pre-trained TensorFlow models. artificial intelligence (AI) Bundled No Code Rules Engine Plugin A Simple Rules Engine Decision plugin is bundled, providing a no-code configurable approach to define routing and actions within a process. Other Notable Platform Upgrades Enhanced Permission Management in App Builder Advanced Tools Support for Pluggable App Builders Upgraded JavaScript (JQuery, JQuery UI and Bootstrap) Libraries Get Started with Joget DX Download the and test it out today. This Preview Release is intended to showcase features and provide early access to upcoming product innovations, allowing the community to the test functionality and provide feedback during the development process. Joget DX Preview Release

Joget DX Open Source Digital Transformation Platform Now Available for Preview

Salesforce DX is the new development environment that will eventually replace the Salesforce EDI that’s based on Eclipse. Recently, Salesforce announced that they won’t release any new feature for the Salesforce EDI any longer. While they will still support it until October 12th, 2019 all new features will be released for Salesforce DX. . On Oct. 12th, 2019 we will no longer provide support or updates of any kind to the Force.com IDE Having said that, Salesforce DX stands for Salesforce Developer Experience and just follows the trend that Salesforce has chosen for its platform. Rather than being exclusive and very separated with they want to stay up to date with the latest trends and development environments. Before, you had to choose between the built-in Developer Console or Salesforce EDI. Both weren’t ideal and very outdated compared to other solutions. Yes, there are 3rd party solutions such as Welkin Suite that leverage the Salesforce API but I wasn’t convinced that any of those were really 100% as good as my JavaScript Development environment for example. Salesforce DX takes advantage of the very popular open source editor Visual Studio Code and has published all its add-on exclusively for that platform (as of right now). Therefore, if you want to develop there are a couple of add-ons that are required to use Visual Studio Code for Salesforce Development. They offer APEX syntax support and various API integration to manage your projects. Additionally, Salesforce wants to make sure that you integrate your development efforts with Git, specifically GitHub. That allows you to keep track of any changes in your code and traceback code snippets to a specific point of time and developer. If you are familiar with GitHub, you are most likely familiar with the concept of branches and pull-requests that allow you to develop various features simultaneously without affecting the main (master branch) code. From there, you can deploy those versions on separate instances and test those accordingly. Salesforce allows a very similar behavior by allowing developers to leverage Scratch Orgs. You are already familiar with Sandboxes, which are used for development and testing purposes. A Scratch Org is basically a developer environment that allows developers to easily push and pull the code that lies in separates branches. Therefore, it can be developed independently before releasing for testing. Additionally, the newly released Salesforce CLI allows you to manage those scratch orgs and log in from the terminal. That makes managing your credentials 10x easier. Once it’s set up, you are able to push and pull code as well as a login at any point of time without remembering your login for that specific org. We truly believe that Salesforce DX is a brilliant move in the right direction for Salesforce and demonstrates the wisdom of Salesforce’s direction. Before you can start with Salesforce DX, you to enable the Development Hub for the organization you are working in. That’s amiable under the regular Setup and can easily be enabled with a click of a button. From there, you have to install the Salesforce CLI. You can install it via a package ( ) or npm ( ). For npm enter the following in your terminal: click here click here npm install sfdx-cli --global Now that you have installed the Salesforce CLI you can take advantage of the following commands: sfdx force — help shows you all available force commands Additionally, you can look up the official documentation as well right or run: here sfdx force:doc:commands:list At any given time, you can easily add to get some guidance in regards to what options are available. Especially, in the beginning, you will find this particularly useful because there are so many CLI commands. — help From here, you create a new folder that will store & manage all your source code. To get started, you have to maintain your Salesforce connections. I started with my production environment to get the initial status quo and all dependencies that are required to do actual development through Salesforce DX going forward. sfdx force:auth:web:login --setalias my-hub-org --instanceurl url Having the correct origination connected to your CLI brings you to the next step before you can start your development. In the Setup, create a new package and include all dependencies and custom fields that are required for a copy of your current organizations. This is required when you want to create your Scratch Org later since Scratch Orgs do not include all the customizations you have done your system. That is also the first major difference to a regular sandbox that normally includes all customization you have applied to your Salesforce environment. Since no customizations are included, please make sure to include all managed packages from the App Exchange in your dependencies as well. Otherwise, you will run into errors since those are not included automatically. Once you have created your package, release it, download the full content and unzip it. This will allow you to convert it into a Salesforce DX project. sfdx force:mdapi:retrieve -s -r ./mdapipkg -u [your_username] -punzip ./mdapipkg/unpackaged.zip -d ./mdapipkg/ Now that you have bundled up, all of your customizations and exported it, just run the following command in the Salesforce CLI and it will be converted into a Salesforce DX compatible project that you can use for further development. sfdx force:mdapi:convert -r ./mdapipkg Let’s catch up. We installed the Salesforce CLI, connected to your preferred Salesforce organization, bundled up all customizations, defined dependencies and converted them all into Salesforce DX compatible project. Pretty cool — so far it seems pretty extensive to work with Salesforce DX but I promise that once you have completed this setup, it will get a lot easier and you will appreciate the ease of Salesforce DX (Once again, if you are coming from a JavasScript development world i.e. this will still look crazy to you :)) Set up a new scratch org and upload your complete project. This will pretty much create a Developer Sandbox. Now you can easily, modify existing code and add new functionalities. Additionally, everything from here on works with the typical git push/pull structure. sfdx force:org:create -f project-scratch-def.json -a [ScratchOrgName] To push your Salesforce DX package into the newly created Scratch Org you can use the regular push command: sfdx force:source:push -u [ScratchOrgName] I got stuck, wondering why my latest changes didn’t make it into the scratch org for at least 30 minutes. Let’s say you run into an error that you are using a custom field that doesn’t exist yet but you just skipped over the error message. Unless you modify the file and push it again it won’t show you the error message again. Having said that, it’s very important to read ALL error messages if there are any while you are pushing up your changes. A lot of times, I had the toughest time finding out what was going on and why my modified files weren’t pushed up into the org. Reason for that was an error that was just getting ignored when trying to push again without modifying the actual file. I think that’s a flaw in the current version and will hopefully be something that they will improve going forward. Sign up for our newsletter! © | Better-Built React Solutions | Consulting with success guarantee Syntx.io

Getting Started with Salesforce DX

How to build software experiences that developers love Developers are expected to use increasingly powerful tools to deliver increasingly complex and innovative software. So, why do developer tools often feel like an IRS tax form? I argue that it stems from a culture that treats aesthetics and functionality as exclusive, whereas I would argue they are highly intertwined. When software is consumer facing, we see a sweeping trend of minimalist elegance aimed at cultivating an emotional connection with the user. But, when that target user is now a developer, design seems to take a back seat to functionality. Still, we must also recognize that developer tools target a very specific user: the developer. These tools typically serve critical functions and are used habitually for highly consequential actions. For many consumer apps, it’s relatively easy for a non-engineer to understand a product’s scope. Let’s take Uber for instance. The UI/UX team assesses the front-end environment, the social caveats, and the broad technical requirements for peer-to-peer transportation. Overall, they are catering to a consumer audience that wants simple, quick, and reliable service. The design team can construct some broad personas and hypotheses regarding transportation from years of empirical experience and common sense. However, building a developer tool is a bit different. Developer tools are not necessarily made to make things less complicated for engineers. They are made to enhance functional power and allow developers to do things that they could never do before. In the past, designers were not core to the development cycle. If the primary purpose was functionality.. why would you focus on usability and aesthetics? “It just needs to work! Not look good!” is what I’ve heard in the past. This is the notion that accurately performing a task correlates to function, that putting in the correct inputs and receiving a reasonable output is the benchmark of success. But, shouldn’t there be other indicators of success? What about time saved? What about ease of use? What about scalability and reliability? What about the ability to make informed decisions? I can show someone a spreadsheet of tabular data or I could show them some informative charts. Both present the same data. Both functionally deliver. But, one works much better at delivering the information and fulfilling its purpose. DX Hence, is about delivering robust functionality that is stable, speedy, and visually intuitive. Developer Experience (DX) Function Function is absolutely paramount. A developer tool is only as good as the functionality it delivers. You cannot mask subpar functionality with beautiful aesthetics or clever marketing. If it doesn’t work well, then it just doesn’t work. Stability Stability is a cornerstone of trust. A critical component of DX is to ensure uptime and dependable performance. Stability also manifests in the ability to rectify errors to avoid critical failure. Without stability, your product becomes unreliable, making your ‘amazing’ functionality irrelevant. Ease of Use Developers hate to take their hands off the keyboard. Every movement to a mouse or trackpad feels like a Herculean task. does not just mean the tool is easy to navigate, but it means that you can access things quickly and efficiently. Keyboard shortcuts, tabular navigation, saved preferences, and intuitive searching/filtering should all increase the speed with which developers can interact with your application. However, is also about performance. User interfaces that take seconds to load instead of milliseconds can be the difference between usable and debilitatingly frustrating. Ease of use ease of use Clarity This category is the closest to aesthetics. DX is about delivering an intuitive interface that surfaces critical information, mitigates user error (ex. confirmation dialogues on critical tasks), and provides visibility into your orientation (ex. navigation through affordance). Clarity is about the developer having full visibility into the potential consequences of an action and into the history of their actions (ex. auditing and analytics). Developers are People Too Just because functionality is paramount does not mean design is not important. Design is about effectively delivering functionality to the developer. The more intuitive your design, the more the developer can take advantage of your product’s core functionality. Design, therefore, is not just aesthetics — it is about usability. For developers, this usability is about surfacing functionality as quickly and intuitively as possible. You can be the most patient engineer in the world, but if you are using a product that combines enterprise-grade functionality with an unusable interface, then your life will be filled with frustration and pain. We must remember: . When we embrace DX, we catalyze the growth of more powerful developer tools. developers are people who value well-designed things To learn more about DX, I recommend the podcast series “ Don’t Make Me Code ” hosted by Stephen Boak and David Dollar. More specifically, Episode 5 discusses how Developers are people too and the associated implications for DX.

Developer Experience (DX) — Devs Are People Too

I’m going to share my experience building , an open-source realtime logging tool for node.js, specifically solving a pain for the community. now-logs now Developer Experience (DX) My definition for DX is simple: “DX is how developers feel while using your tools, code and APIs” The thing I am most impressed with working with , is the focus on DX and how it makes me feel. Every tool I use . The creators invested a lot of thought into every small detail and it shows. now makes me feel happy and smart I decided to have DX as a main feature of . I wanted it to feel like , be and to use. now-logs magic fast to integrate super simple In the end, 3 things made the DX great: 1. Killing the sign-up process Developers just want to start using a tool without signing up for a service. However, services usually require you to sign up to get your private API_KEY. Let’s remove this step so . developers can jump straight to code In order to avoid a signup step, developers can just come up with their own API_KEY and use that. If chosen wisely, there should be no collisions. Now you can start using with a magical one liner: now-logs require(‘now-logs’)(‘ ’); the-api-key-i-came-up-with 2. Not inventing new workflows Developers are viewing logs in their terminal, but all 3rd party logging solutions requires you to login to a website to see the logs. and get us back to the terminal where we belong. Let’s fix that Fortunately, creating command line tools in node.js is a breeze. is a super simple command line tool: now-logs now-logs the-api-key-i-came-up-with With this in your terminal, feel free to pipe (|) and direct (>) your output to other programs. This makes me . feel at home 3. Investing in website & documentation A good website can have enormous impact on the usage of tools and open source libraries. About 1/2 of the effort building was directed to the ’s copy, the and the output of the cli tool. now-logs website GitHub README.md usage now-logs The website is both a demo and tutorial so within 1 minute you should know if you should be using or not. now-logs Checkout find me on Twitter ( ). now-logs ketacode

3 Lessons about DX from building “now-logs”

Flutter vs NativeScript — Key Differences and Why we Switched in the Middle of the Road

Majority Voting Approach to Ransomware Detection: References and Appendix

Author:
(1) V V Obukhov, Institute of research and development, Tomsk State Pedagogical University, Kievskaya str. 60, Tomsk 634061, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia (E-mail: obukhov@tspu.edu.ru);
(2) K E Osetrin, Center for Mathematical and Computer Physics, Tomsk State Pedagogical University, Kievskaya str. 60, Tomsk 634061, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia;
(3) A V Shapovalov, Department of Theoretical Physics, National Research Tomsk State University, Lenina pr. 36, Tomsk 634050, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia. Table of Links Abstract and Introduction Conclusion, Statements and Declarations, and Bibliography Conclusion Summarising, we believe that the statement made in the papers [1, 2] about new scientific results in the problem of complete separation of variables in the HamiltonJacobi equation for geodesics does not correspond to reality. We did not find any new results in comparison with those contained in the theorem on necessary and sufficient conditions of Vladimir N. Shapovalov. The results of the article in question, unlike the original ones, have omissions, and the article contains incorrect statements. Thus, the methods and results proposed in the works [1, 2] do not contain scientific novelty and represent a special case of the theory of complete separation of variables in the free Hamilton-Jacobi equation, finally constructed in the 70s of the last century. Statements and Declarations Data availability statement All necessary data and references to external sources are contained in the text of the manuscript. All information sources used in the work are publicly available and refer to open publications in scientific journals and textbooks. Compliance with Ethical Standards The authors declare no conflict of interest. Bibliography [1] Katanaev M O, Complete separation of variables in the geodesic HamiltonJacobi equation in four dimensions, 2023 Physica Scripta 98 104001 URL https://dx.doi.org/10.1088/1402-4896/acf251 [2] Katanaev M O 2023 Complete separation of variables in the geodesic Hamilton-Jacobi equation (Preprint 2305.02222) URL https://arxiv.org/abs/2305.02222 [3] Obukhov V, Hamilton–Jacobi equation for a charged test particle in the St¨ackel space of type (2.0), 2020 Symmetry 12 URL https://www.mdpi.com/2073-8994/12/8/1289 [4] Obukhov V, Separation of variables in Hamilton–Jacobi equation for a charged test particle in the St¨ackel spaces of type (2.1), 2020 International Journal of Geometric Methods in Modern Physics 17 2050186 URL https://doi.org/10.1142/S0219887820501868 [5] Obukhov V, Separation of variables in Hamilton–Jacobi and Klein–Gordon–Fock equations for a charged test particle in the St¨ackel spaces of type (1.1), 2021 International Journal of Geometric Methods in Modern Physics 18 2150036 URL https://doi.org/10.1142/S0219887821500365 [6] Obukhov V V 2006 St¨ackel spaces in gravity theory (Tomsk: Tomsk State Pedagogical University) ISBN 978-5-89428-242-8 [7] Bagrov V G, Meshkov A G, Shapovalov V N and Shapovalov A V, Separation of variables in the Klein-Gordon equations. I, 1973 Soviet Physics Journal 16 1533–1538 URL https://doi.org/10.1007/BF00889957 [8] Shapovalov V N, Symmetry and separation of variables in Hamilton-Jacobi equations. I, 1978 Soviet Physics Journal 21 1124–1129 URL https://doi.org/10.1007/BF00894559 [9] Shapovalov V N, St¨ackel spaces, 1979 Siberian Mathematical Journal 20 790–800 URL https://doi.org/10.1007/BF00971844 [10] Bagrov V G, Obukhov V V and Shapovalov A V, Special St¨ackel electrovac spacetimes, 1986 Pramana - J. Phys. 26 93–108 URL https://doi.org/10.1007/BF02847629 [11] Bagrov V G and Obukhov V V, Classes of exact solutions of the Einstein–Maxwell equations, 1983 Annalen der Physik 495 181–188 URL https://doi.org/10.1002/andp.19834950402 [12] Bagrov V G, Obukhov V V and Osetrin K E, Classification of null St¨ackel electrovac metrics with cosmological constant, 1988 General Relativity and Gravitation 20 1141–1154 URL https://doi.org/10.1007/BF00758935 This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Author: (1) V V Obukhov, Institute of research and development, Tomsk State Pedagogical University, Kievskaya str. 60, Tomsk 634061, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia (E-mail: obukhov@tspu.edu.ru); (2) K E Osetrin, Center for Mathematical and Computer Physics, Tomsk State Pedagogical University, Kievskaya str. 60, Tomsk 634061, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia; (3) A V Shapovalov, Department of Theoretical Physics, National Research Tomsk State University, Lenina pr. 36, Tomsk 634050, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia. Author: Author: (1) V V Obukhov, Institute of research and development, Tomsk State Pedagogical University, Kievskaya str. 60, Tomsk 634061, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia (E-mail: obukhov@tspu.edu.ru); (2) K E Osetrin, Center for Mathematical and Computer Physics, Tomsk State Pedagogical University, Kievskaya str. 60, Tomsk 634061, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia; (3) A V Shapovalov, Department of Theoretical Physics, National Research Tomsk State University, Lenina pr. 36, Tomsk 634050, Russia & International laboratory of theoretical cosmology, Tomsk State University of Control Systems and Radioelectronics, Lenina pr. 40, Tomsk 634050, Russia. Table of Links Abstract and Introduction Abstract and Introduction Conclusion, Statements and Declarations, and Bibliography Conclusion, Statements and Declarations, and Bibliography Conclusion Summarising, we believe that the statement made in the papers [1, 2] about new scientific results in the problem of complete separation of variables in the HamiltonJacobi equation for geodesics does not correspond to reality. We did not find any new results in comparison with those contained in the theorem on necessary and sufficient conditions of Vladimir N. Shapovalov. The results of the article in question, unlike the original ones, have omissions, and the article contains incorrect statements. Thus, the methods and results proposed in the works [1, 2] do not contain scientific novelty and represent a special case of the theory of complete separation of variables in the free Hamilton-Jacobi equation, finally constructed in the 70s of the last century. Statements and Declarations Data availability statement Data availability statement All necessary data and references to external sources are contained in the text of the manuscript. All information sources used in the work are publicly available and refer to open publications in scientific journals and textbooks. Compliance with Ethical Standards Compliance with Ethical Standards The authors declare no conflict of interest. Bibliography [1] Katanaev M O, Complete separation of variables in the geodesic HamiltonJacobi equation in four dimensions, 2023 Physica Scripta 98 104001 URL https://dx.doi.org/10.1088/1402-4896/acf251 [2] Katanaev M O 2023 Complete separation of variables in the geodesic Hamilton-Jacobi equation (Preprint 2305.02222) URL https://arxiv.org/abs/2305.02222 [3] Obukhov V, Hamilton–Jacobi equation for a charged test particle in the St¨ackel space of type (2.0), 2020 Symmetry 12 URL https://www.mdpi.com/2073-8994/12/8/1289 [4] Obukhov V, Separation of variables in Hamilton–Jacobi equation for a charged test particle in the St¨ackel spaces of type (2.1), 2020 International Journal of Geometric Methods in Modern Physics 17 2050186 URL https://doi.org/10.1142/S0219887820501868 [5] Obukhov V, Separation of variables in Hamilton–Jacobi and Klein–Gordon–Fock equations for a charged test particle in the St¨ackel spaces of type (1.1), 2021 International Journal of Geometric Methods in Modern Physics 18 2150036 URL https://doi.org/10.1142/S0219887821500365 [6] Obukhov V V 2006 St¨ackel spaces in gravity theory (Tomsk: Tomsk State Pedagogical University) ISBN 978-5-89428-242-8 [7] Bagrov V G, Meshkov A G, Shapovalov V N and Shapovalov A V, Separation of variables in the Klein-Gordon equations. I, 1973 Soviet Physics Journal 16 1533–1538 URL https://doi.org/10.1007/BF00889957 [8] Shapovalov V N, Symmetry and separation of variables in Hamilton-Jacobi equations. I, 1978 Soviet Physics Journal 21 1124–1129 URL https://doi.org/10.1007/BF00894559 [9] Shapovalov V N, St¨ackel spaces, 1979 Siberian Mathematical Journal 20 790–800 URL https://doi.org/10.1007/BF00971844 [10] Bagrov V G, Obukhov V V and Shapovalov A V, Special St¨ackel electrovac spacetimes, 1986 Pramana - J. Phys. 26 93–108 URL https://doi.org/10.1007/BF02847629 [11] Bagrov V G and Obukhov V V, Classes of exact solutions of the Einstein–Maxwell equations, 1983 Annalen der Physik 495 181–188 URL https://doi.org/10.1002/andp.19834950402 [12] Bagrov V G, Obukhov V V and Osetrin K E, Classification of null St¨ackel electrovac metrics with cosmological constant, 1988 General Relativity and Gravitation 20 1141–1154 URL https://doi.org/10.1007/BF00758935 This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Revisiting Separation of Variables in Hamilton-Jacobi Equations: Conclusion, Statements and More

Authors:
(1) Fabiano Villan, Universidade Luterana do Brasil (ULBRA), Curso de Licenciatura em Física;
(2) Renato P. dos Santos, Universidade Luterana do Brasil (ULBRA), PPG em Ensino de Ciências e Matemática (PPGECIM). Table of Links Abstract Introduction Theoretical Framework The ZPD and Chat GPT as a Co-Advisor in Scientific Guidance Methodology Results and Analysis Conclusions, Acknowledgements, Author's Contribution Statement, Data Availability Statement References APÊNDICE A APÊNDICE B REFERENCES Adams, C., Pente, P., Lemermeyer, G., & Rockwell, G. (2023). Ethical principles for artificial intelligence in K-12 education. Computers and Education: Artificial Intelligence, 4, 100131. https://doi.org/10.1016/j.caeai.2023.100131 Aureliano, F. E. B. S. & Queiroz, D. E. de (2023). As Tecnologias Digitais como Recursos Pedagógicos no Ensino Remoto: Implicações na Formação Continuada e nas Práticas Docentes. Educação em Revista, 39. https://doi.org/10.1590/0102-469839080 Borges, F. M., Rita, C. P. B., & Vitérico, J. M. (2022). Elementos mobilizados pelo professor no processo de orientação de iniciação científica na educação básica. Actio, Curitiba, 8(2), 1-17 Borges, R. de C. P. & Borges, M. F. (2018). Elementos mobilizados pelo professor no processo de orientação de iniciação científica na educação básica. In: Peixoto, A., Oliveira, J., Gonçalves, J., Luísa Neves, Rita Cruz. Atas do XVII Encontro Nacional de Educação em Ciências, XVII ENEC, I Seminário Internacional de Educação em Ciências, I SIEC, Viana do Castelo, fevereiro de 2018. (p. 404-410). Brasil. (2015). Conselho Nacional de Desenvolvimento Científico e Tecnológico. Iniciação Científica Junior – ICJ. https://www.gov.br/mcti/pt-br/acompanhe-o-mcti/bolsacientifica/saiba-mais Brasil. (2018). Ministério da Educação. Base Nacional Comum Curricular. Brasília. http://basenacionalcomum.mec.gov.br/images/BNCC_EI_EF_110518 _versaofinal_site.pdf da Silveira, J. C., Cassiani, S., & Von Linsingen, I. (2018). Escrita e autoria em texto de iniciação científica no ensino fundamental: uma outra relação com o saber é possível? Ciência e Educação, Bauru, 24(1), 9- 25 de Cássia Nakano, T., Primi, R., & Alves, R. J. R. (2021). 21st century skills: relationship between creativity and socioemotional skills in Brazilian students. Educar em Revista, 37, e81544. http://dx.doi.org/10.1590/0104-4060.81544 Fisher, R. A. (1935). The Design of Experiments. Oliver and Boyd. Freire, P. (1996). Pedagogia da autonomia: saberes necessários à prática educativa. 25. ed. Paz e Terra. Gil-Pérez, D. & Carvalho, A. M. P. de. (2001). Formação de Professores de Ciências: tendências e inovações. 6. ed. Hernández, F. & Ventura, M. (1998). A organização do currículo por projetos de trabalho: O conhecimento é um caleidoscópio. Artmed. Kemmis, S., & McTaggart, R. (Eds.). (1988). The action research planner. Deakin University. Lewin, K. (1946). Action research and minority problems. In G. W. Lewin (Ed.), Resolving social conflicts; selected papers on group dynamics (pp. 201-216). Harper & Row. Mekari. D. (2023). Linha do tempo: história da inteligência artificial. https://porvir.org/linha-do-tempo-historia-da-inteligencia-artificial-naeducacao . Nascimento, M. B. da C. & Morosini, M. (2019). Perspectives, Scope and Meanings of Scientific Initiation in Scientific Productions. Rev. Tempos Espaços Educ., São Cristóvão, 12(29), 161-176. http://doi.org/10.20952/revtee.v12i29.9825 National Academies of Sciences, Engineering, and Medicine. (1997). Science Teaching Reconsidered: A Handbook. The National Academies Press. https://doi.org/10.17226/5287. Perrenoud, P. (2000). Dez novas competências para ensinar. Artmed. Rodrigues, H. (2021). Como a tecnologia pode impactar a educação no século 21. Forbes. https://forbes.com.br/forbescollab/2021/08/haroldo-rodrigues-como-a-tecnologia-pode-impactara-educacao-do-seculo-21/ Saliba, T. A., Custodio, L. B. de M., Saliba, N. A., & Moimaz, S. A. S. (2019). O impacto da Iniciação Científica na produção bibliográfica de pós-graduandos. Revista da ABENO, 19(1), 127–133. https://doi.org/10.30979/rev.abeno.v19i1.873 Santos, A.L.C., Silva, F.V.C., Santos, L.G.T., & Aguiar, A.A.F.M. (2020). Dificuldades apontadas por professores do programa de mestrado profissional em ensino de biologia para o uso de metodologias ativas em escolas da rede pública na Paraíba. Revista Brasileira de Desenvolvimento, 6(4), 21959–21973. Schmidt, H.G. (2012). A Brief History of Problem-based Learning. In: O'Grady, G., Yew, E., Goh, K., Schmidt, H. (eds) One-Day, OneProblem. Springer. https://doi.org/10.1007/978-981-4021-75-3_2 Servant‐Miklos, V. F. C., Norman, G., & Schmidt, H. (2019). A Short Intellectual History of Problem‐Based Learning. In: The Wiley Handbook of Problem‐Based Learning. http://doi.org/10.1002/9781119173243.CH1 Silva, J. M. & Paniago, M. C. L. (2022). TDIC nas licenciaturas: discutindo resistências. Anais VIII CONEDU. Realize. https://www.editorarealize.com.br/index.php/artigo/visualizar/88333 Vygotsky, L. S. (1991). A Formação Social da Mente. Martins Fontes. Vygotsky, L. S. (2001). Aprendizagem e desenvolvimento intelectual na idade escolar. In: Vygotsky, L. S.; Luria, A. R.; Leontiev, A. Linguagem, Desenvolvimento e Aprendizagem. 9. ed. Ícone APÊNDICE A APÊNDICE B This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Fabiano Villan, Universidade Luterana do Brasil (ULBRA), Curso de Licenciatura em Física; (2) Renato P. dos Santos, Universidade Luterana do Brasil (ULBRA), PPG em Ensino de Ciências e Matemática (PPGECIM). Authors: Authors: (1) Fabiano Villan, Universidade Luterana do Brasil (ULBRA), Curso de Licenciatura em Física; (2) Renato P. dos Santos, Universidade Luterana do Brasil (ULBRA), PPG em Ensino de Ciências e Matemática (PPGECIM). Table of Links Abstract Abstract Introduction Introduction Theoretical Framework Theoretical Framework The ZPD and Chat GPT as a Co-Advisor in Scientific Guidance The ZPD and Chat GPT as a Co-Advisor in Scientific Guidance Methodology Methodology Results and Analysis Results and Analysis Conclusions, Acknowledgements, Author's Contribution Statement, Data Availability Statement Conclusions, Acknowledgements, Author's Contribution Statement, Data Availability Statement References References APÊNDICE A APÊNDICE A APÊNDICE B APÊNDICE B REFERENCES Adams, C., Pente, P., Lemermeyer, G., & Rockwell, G. (2023). Ethical principles for artificial intelligence in K-12 education. Computers and Education: Artificial Intelligence, 4, 100131. https://doi.org/10.1016/j.caeai.2023.100131 Aureliano, F. E. B. S. & Queiroz, D. E. de (2023). As Tecnologias Digitais como Recursos Pedagógicos no Ensino Remoto: Implicações na Formação Continuada e nas Práticas Docentes. Educação em Revista, 39. https://doi.org/10.1590/0102-469839080 Borges, F. M., Rita, C. P. B., & Vitérico, J. M. (2022). Elementos mobilizados pelo professor no processo de orientação de iniciação científica na educação básica. Actio, Curitiba, 8(2), 1-17 Borges, R. de C. P. & Borges, M. F. (2018). Elementos mobilizados pelo professor no processo de orientação de iniciação científica na educação básica. In: Peixoto, A., Oliveira, J., Gonçalves, J., Luísa Neves, Rita Cruz. Atas do XVII Encontro Nacional de Educação em Ciências, XVII ENEC, I Seminário Internacional de Educação em Ciências, I SIEC, Viana do Castelo, fevereiro de 2018. (p. 404-410). Brasil. (2015). Conselho Nacional de Desenvolvimento Científico e Tecnológico. Iniciação Científica Junior – ICJ. https://www.gov.br/mcti/pt-br/acompanhe-o-mcti/bolsacientifica/saiba-mais Brasil. (2018). Ministério da Educação. Base Nacional Comum Curricular. Brasília. http://basenacionalcomum.mec.gov.br/images/BNCC_EI_EF_110518 _versaofinal_site.pdf da Silveira, J. C., Cassiani, S., & Von Linsingen, I. (2018). Escrita e autoria em texto de iniciação científica no ensino fundamental: uma outra relação com o saber é possível? Ciência e Educação, Bauru, 24(1), 9- 25 de Cássia Nakano, T., Primi, R., & Alves, R. J. R. (2021). 21st century skills: relationship between creativity and socioemotional skills in Brazilian students. Educar em Revista, 37, e81544. http://dx.doi.org/10.1590/0104-4060.81544 Fisher, R. A. (1935). The Design of Experiments. Oliver and Boyd. Freire, P. (1996). Pedagogia da autonomia: saberes necessários à prática educativa. 25. ed. Paz e Terra. Gil-Pérez, D. & Carvalho, A. M. P. de. (2001). Formação de Professores de Ciências: tendências e inovações. 6. ed. Hernández, F. & Ventura, M. (1998). A organização do currículo por projetos de trabalho: O conhecimento é um caleidoscópio. Artmed. Kemmis, S., & McTaggart, R. (Eds.). (1988). The action research planner. Deakin University. Lewin, K. (1946). Action research and minority problems. In G. W. Lewin (Ed.), Resolving social conflicts; selected papers on group dynamics (pp. 201-216). Harper & Row. Mekari. D. (2023). Linha do tempo: história da inteligência artificial. https://porvir.org/linha-do-tempo-historia-da-inteligencia-artificial-naeducacao . Nascimento, M. B. da C. & Morosini, M. (2019). Perspectives, Scope and Meanings of Scientific Initiation in Scientific Productions. Rev. Tempos Espaços Educ., São Cristóvão, 12(29), 161-176. http://doi.org/10.20952/revtee.v12i29.9825 National Academies of Sciences, Engineering, and Medicine. (1997). Science Teaching Reconsidered: A Handbook. The National Academies Press. https://doi.org/10.17226/5287. Perrenoud, P. (2000). Dez novas competências para ensinar. Artmed. Rodrigues, H. (2021). Como a tecnologia pode impactar a educação no século 21. Forbes. https://forbes.com.br/forbescollab/2021/08/haroldo-rodrigues-como-a-tecnologia-pode-impactara-educacao-do-seculo-21/ Saliba, T. A., Custodio, L. B. de M., Saliba, N. A., & Moimaz, S. A. S. (2019). O impacto da Iniciação Científica na produção bibliográfica de pós-graduandos. Revista da ABENO, 19(1), 127–133. https://doi.org/10.30979/rev.abeno.v19i1.873 Santos, A.L.C., Silva, F.V.C., Santos, L.G.T., & Aguiar, A.A.F.M. (2020). Dificuldades apontadas por professores do programa de mestrado profissional em ensino de biologia para o uso de metodologias ativas em escolas da rede pública na Paraíba. Revista Brasileira de Desenvolvimento, 6(4), 21959–21973. Schmidt, H.G. (2012). A Brief History of Problem-based Learning. In: O'Grady, G., Yew, E., Goh, K., Schmidt, H. (eds) One-Day, OneProblem. Springer. https://doi.org/10.1007/978-981-4021-75-3_2 Servant‐Miklos, V. F. C., Norman, G., & Schmidt, H. (2019). A Short Intellectual History of Problem‐Based Learning. In: The Wiley Handbook of Problem‐Based Learning. http://doi.org/10.1002/9781119173243.CH1 Silva, J. M. & Paniago, M. C. L. (2022). TDIC nas licenciaturas: discutindo resistências. Anais VIII CONEDU. Realize. https://www.editorarealize.com.br/index.php/artigo/visualizar/88333 Vygotsky, L. S. (1991). A Formação Social da Mente. Martins Fontes. Vygotsky, L. S. (2001). Aprendizagem e desenvolvimento intelectual na idade escolar. In: Vygotsky, L. S.; Luria, A. R.; Leontiev, A. Linguagem, Desenvolvimento e Aprendizagem. 9. ed. Ícone APÊNDICE A APÊNDICE B This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Stories, News & Mentions about DX

Dx’s Stories on HackerNoon