AODocs makes it simple to migrate files from legacy document management systems, implement business workflows, and apply document retention policies for enterprise collaboration on Google Drive and One Drive

AODocs

Software Testing Companies To Look Out For in 2023

HackerNoon Reporter: Please tell us briefly about your  background. I am Surbhi Rathore, the CEO and cofounder of . Symbl is a programmable platform that empowers developers and businesses to monitor, act, and comply with voice, video conversations at scale in their products and workflows without building their in-house data science expertise. Symbl.ai I am a Techstars alum, co-founded Symbl almost 3 years ago and is now backed by Amazon and has raised an early-stage venture round of $6.5M which deployed capital to grow a global team of tech enthusiasts to more than 50 people. For more than a decade, I have worked in technical and customer-obsessed roles in both startups and enterprises such as Nevis Networks and Amdocs. Before co-founding Symbl, I worked in the Conversational AI space with a focus on delivering value to Telecommunication users. With a geographically distributed presence, I am excited to be an international tech leader who advocates for Women in AI with a personal mission to inspire more women to work in Data Science. I am a national speaker, an accessibility equity champion, and the ultimate venture capitalist. I have been honored with the Women in Voice Award for Founder of the Year, Amazon’s Top 10 Women to Watch in 2020, and the Will Reed Top 50 Companies in 2021. What's your startup called? And in a sentence or two, what does it do? Symbl enables developers to build next-generation AI-powered communication experiences with APIs that deliver the most relevant and accurate speech recognition and contextual intelligence in milliseconds. We are proud to be empower a community of builders that are championing the voice-first movement and pushing the limits of how conversation data is used for the growth of individuals and businesses. Businesses building with Symbl are enabled to build more inclusive and accessible communication applications with live captioning, AI-powered search and indexing, real-time call tracking for coaching, compliance, automation and more. What is the origin story? My co-founder Toshish and I were working on a conversation AI platform for the telecom domain to make it easy for telco businesses to adopt conversational interfaces in their self-service applications - enabling chatbots and virtual assistants for basic telco workflows. We had a strong thesis that while chatbots will help automate some functions, talking to humans will never go away. We had the opportunity to experience customer conversations at scale in the Telecom domain and see firsthand the impact of AI/ML. Owing to the limitations of not being able to use existing technologies to contextually comprehend human conversations that are by far the most chaotic and unstructured data and to be able to passively listen to conversations on calls and videos and provide recommendations to users to do better, we started Symbl. What do you love about your team, and why are you the ones to solve this problem? We are a platform by builders, for builders. Our team is built with engineers and experts that are passionate about solving problems with AI/ML at the intersection of communication tools. We never give up and are hustlers and opportunity seekers, who are customer-obsessed and only care about delivering the best experience to our developers and customers. We are a diverse team from several cultures and backgrounds coming together and working as one big family. We thrive on innovation and ideas that are brought, worked, and nurtured in an open environment without the biases of who started what! If you weren’t building your startup, what would you be doing? If I were not building Symbl to democratize conversation intelligence tech for developers, I would build Symbl to solve the adoption of AI/ML in the telco space which I have spent years in. I know the value of shaving even seconds off a call. Roles don’t matter, but I am sure I’d be helping create value and opportunities for the maturity of the voice ecosystem. At the moment, how do you measure success? What are your core metrics? Customer happiness and product value are the ultimate success metrics for our company. Another important one that I like to add is employee growth since that people are really what defines the journey of the company. What’s most exciting about your traction to date? Symbl is working with some of the world’s best high growth VC-backed startups like Airmeet, Yac, Hubilo, Racket, RevenueGrid, Moonbeam. It is so exciting to work with other founders that are equally passionate about changing the landscape of online communications in this new normal. We are also extremely excited and proud to partner up with with - the leading developer platform for real-time engagement for voice and video in just a year of releasing our platform. Agora.io We continue to collaborate with community drivers like Postman, and AWS to make it seamless to adopt conversation intelligence over voice or video applications. Dolby.io What technologies are you currently most excited about, and most worried about? And why? I am really excited about the evolution and maturity of the NLP landscape and how that gets applied to speech, audio and video interfaces. We are losing extremely valuable data today in voice conversations and leveraging that for the next generation of experiences that I am personally very excited about. What drew you to get published on HackerNoon? What do you like most about our platform? I have always been drawn to community platforms where people can authentically connect, collaborate and learn from each other - and HackerNoon lies in the centre of builders supporting builders! What advice would you give to the 21-year-old version of yourself? Backpack around the world and then join a startup where you can make an impact early on. P.S There is no better way to learn than to collaborate with other diverse cultures and minds. What is something surprising you've learned this year that your contemporaries would benefit from knowing? Customer stories are the most important part of an early-stage business for investors, new team members and also other prospects to understand the value of your platform in an authentic way. Time-box writing a case study with the first customer you sign in 3 months of working with them to be sure you are able to quantify value. Don’t forget to vote for Symbl.AI as . Startup of the Year in Seattle

Interview with CEO & Co-founder of Symbl.AI

Top Custom Software Development Companies

Automation in finances, particularly within the banking sector, traditionally commenced with high-frequency processes and transactions. In banking, the most frequent activities involve transaction processing and retail lending. These areas have been the primary focus of automation efforts, encompassing aspects such as application processing, risk assessment, and the transition from manual review of forms and documents to automated checks and model-based evaluations. Mezzanine financing stands in stark contrast to these high-frequency processes. Characterized by its unique, tailor-made nature, mezzanine financing occupies a specific niche space within the financial landscape: it represents a financing solution with heightened risk levels, strategically positioned between standard corporate loans and equity investments. Mezzanine financing either involves providing funding at the shareholder level (which is structural subordination) or through equity acquisition coupled with return instruments like put options (contractual subordination). Given the one-off and highly individualized nature of mezzanine deals, automating processes in this area presents a significant challenge. The natural question would be the following: how can banks, especially major ones, approach the task of enhancing the profitability of their mezzanine business through automation and digital transformation? As an expert with substantial experience in the areas of Private Equity, Risk Management, and Finance, I aim to provide an introductory exploration into the digital transformation in mezzanine lending which seeks to unravel the complexities and provide success stories in applying technological advancements to an area of banking traditionally reliant on bespoke, individualized deal-making. The Traditional Landscape of Mezzanine Lending Mezzanine financing is a distinctive and nuanced sector within the broader financial landscape. As was stated earlier, it occupies a middle ground between conventional corporate loans and equity investments and is characterized by an elevated risk level. Uniquely, each mezzanine deal is tailor-made, and crafted to suit the specific needs and circumstances of each client, much like a custom-made suit. Challenges in Traditional Mezzanine Lending The nature of mezzanine financing inherently brings about significant challenges. Traditional methods rely mainly on manual processes and individualized deal-making. This approach demands a deep understanding of the unique aspects of each deal, a skill set that is often . scarce and expensive In large banks with established corporate lending divisions, client and credit managers are well-versed in standard credit products. However, their encounter with mezzanine transactions is infrequent, which in turn limits their expertise in effectively selling or attracting such deals. Establishing a specialized team of client managers exclusively for mezzanine products is not just expensive, but it also escalates the costs in comparison to the more standard lending procedures. While it is possible to combine complex investment products into groups to reduce costs, digitalization in this regard emerges as a more economical and efficient alternative. Digitalization as a Solution The digital transformation in mezzanine lending primarily focuses on deal identification and attraction. Most credit and client specialists in banks use systems that record negotiations, deal ideas, and initial deal parameters. Integrating mezzanine criteria into these existing systems could automate the identification of potential mezzanine deals. When a transaction meets these criteria, it could automatically be forwarded to the mezzanine division for further processing. Further advancements might include AI models trained to differentiate between standard corporate loans and mezzanine deals based on a multitude of incoming deal parameters. The scale of this transformation is significant: while a major bank might conduct thousands of corporate lending transactions annually, mezzanine financing deals are much rarer, often numbered in single digits. Implementing a system for identifying mezzanine deals could potentially lead to a tenfold increase in their volume. Streamlining the Process: Automation and Standardization Digital transformation can streamline execution by automating and standardizing the process. Instead of diving straight into full-scale automation and platform development, you could initially focus on simpler technologies like RPA, which automate data collection, verification, calculation, and reporting. This reduces manual work and errors and improves accounting and compliance. Standardized mezzanine instruments and documents like term sheets and loan agreements can also be quickly customized for each deal without loss of quality. This speeds up processing and documentation, which further improves transparency and consistency. Digital platforms and tools like databases and dashboards help track and manage increased deal volume and variety by organizing information. This enables monitoring deal status and progress, identifying and resolving issues. Overall, automation and standardization simplify execution, reducing friction and costs. By streamlining the end-to-end process, digital transformation makes mezzanine lending more efficient, scalable, and profitable. The Role of Reporting Tools Mezzanine portfolio reporting is problematic without standardized data. These heterogeneous deals lack transparency, which makes it difficult to consistently evaluate key return and risk metrics. Digital analytics tools for data visualization and Business Intelligence can help by integrating fragmented data for consolidated visibility: it enables interactive dashboards that visualize portfolio performance sliced by the borrower, industry, geography, and other dimensions — this empowers holistic monitoring. also enables advanced analytics like predictive modeling, scenario analysis, and stress testing. Lenders can simulate future portfolio performance under various assumptions and conditions — these data-driven insights help optimize strategy and risk mitigation. Qlik and data analytics in this regard are the best to provide the transparency and insights needed to actively manage mezzanine portfolios. By enabling comprehensive reporting and predictive analytics on these complex deals, digital transformation gives lenders the visibility required to maximize returns and minimize risk. It's a powerful lever for optimizing results in mezzanine lending. Qlik Sense Case Studies In this section, we'll explore instances of credit process automation. Notably, there are limited prominent cases of optimizing mezzanine transactions beyond our work at Sberbank. However, I'll present some examples that demonstrate how similar approaches can be applied to mezzanine business, akin to what we achieved at Sberbank between 2018 and 2021, and what I’ll unveil later in the text. Case Study 1: Major European Bank Implements End-to-End Digital Lending Platform : A large European bank sought to reposition its SME lending business amid competition from agile fintech rivals. It aimed to create a digital ecosystem with seamless customer journeys. The first step was reinventing its commercial lending with streamlined applications, mobile access, and real-time approvals. Background : The bank partnered with Deloitte to define customer and technology requirements for a new cloud-based Digital Lending System. Deloitte's OpenDATA platform on AWS enabled flexible, scalable, modular development. This allowed the adoption of Agile methodologies, delivering the first version in just 13 weeks. Approach The system uses advanced analytics including AI and ML to integrate and analyze data from internal systems, external databases, social media, and other sources to create comprehensive, up-to-date borrower profiles. It applies predetermined rules to filter and rank suitability for mezzanine financing. RPA, blockchain, and smart contracts automate manual tasks like documentation, calculations, and reporting. Qlik Sense enables interactive data visualization, predictive modeling, scenarios, and stress testing to optimize mezzanine strategies and risk management. As a result, the loan application time was reduced from 20 days to 15 minutes, the approval rate increased from 50% to 90%, and processing costs decreased by 70%. Lead flow, quality, and conversion also improved, whereas transparency and consistency of mezzanine offerings were enhanced. Analytics and simulations optimized strategies and decisions. Case Study 2: Private Lending Company Leverages GoDocs to Modernize Lending : theLender is a private lending company that specializes in providing bridge loans to real estate investors. theLender sought to differentiate itself from other lenders by offering a faster, simpler, and more transparent lending process. Background : The company partnered with GoDocs, a leading provider of commercial loan document generation software, to implement a digital lending platform that automates the entire loan origination and closing process. Approach The platform leverages cloud computing, artificial intelligence, and blockchain technology to streamline workflows, reduce errors, and enhance security. Further, theLender’s digital lending platform enabled it to reduce the time to generate loan documents from hours to minutes, eliminate manual data entry and human errors, provide real-time visibility and collaboration among all parties involved in the loan transaction, securely store and share loan documents on a distributed ledger, and finally integrate with third-party services such as credit bureaus, title companies, and escrow agents. As a result, the company’s digital lending platform helped it increase its loan volume and revenue by 300% in one year, improve its customer satisfaction and retention rates, reduce its operational costs and risks, as well as gain a competitive edge in the private lending market. Conclusion Digital transformation presents a compelling opportunity for mezzanine lenders to innovate and create value. Advanced technologies including automation, AI, and data analytics can address current pain points around deal sourcing, process efficiency, and portfolio management. The potential benefits are multifaceted — improved customer experience, employee productivity, risk management, and strategic agility. The main benefit is an increase in the number of transactions, and therefore in income. Drawing on my experience working at Sberbank from 2018 to 2021, it's clear that implementing such changes in the mezzanine business can significantly boost both the volume of business and the number of deals. Initially, Sberbank managed around 10 mezzanine deals per year. However, by 2022, following the adoption of effective automation strategies, the bank's capacity surged to over 100 deals annually. This remarkable growth highlights the substantial influence of digital innovations on enhancing both the scale and efficiency of operations in mezzanine lending.

Digital Transformation Success Stories in Mezzanine Lending

In this post, I want to show how you can implement your own tool using the HCL format.
The HCL configuration format is used by all the amazing HasiCorp tools like , , and . Terraform Vault Nomad Most modern applications and tools use YAML these days which is generally an easy-to-read format but can also be the cause of a lot of pain because of the white space sensitivity. HCL on the other hand provides an easy-to-read format with a clear structure and additional features like variable interpolation and inline function calls. Let's start with a really simple example to parse HCL. task "first_task" {
    exec "list_current_dir" {
        command = "ls ."
    }

    exec "list_var_dir" {
        command = "ls /var"
    }
} To map the HCL to our structs we can use struct tags: type Config struct {
    Tasks []*Task `hcl:"task,block"`
}
type Task struct {
    Name  string     `hcl:"name,label"`
    Steps []*ExecStep `hcl:"exec,block"`
}

type ExecStep struct {
    Name    string `hcl:"name,label"`
    Command string `hcl:"command"`
}

func (s *ExecStep) Run() error {
    return nil
} And to decode the HCL we can use the function from the package decode hclsimple import (
    "fmt"
    "os"
    "github.com/hashicorp/hcl/v2/hclsimple"
)

var (
    exampleHCL = `
        task "first_task" {
            exec "list_current_dir" {
                command = "ls ."
            }

            exec "list_var_dir" {
                command = "ls /var"
            }
        }
    `
)

func main() {
    config := &Config{}
    err := hclsimple.Decode("example.hcl", []byte(exampleHCL), nil, config)
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
    for _, task := range config.Tasks {
        fmt.Printf("Task: %s\n", task.Name)
        for _, step := range task.Steps {
            fmt.Printf("    Step: %s %q\n", step.Name, step.Command)
            err = step.Run()
            if err != nil {
                fmt.Println(err)
                os.Exit(1)
            }
        }
    }
} That was easy! But what is if I want to support a different Step type? Let's say I want to support to easily create directories. mkdir task "first_task" {
    mkdir "build_dir" {
        path = "./build"
    }
    exec "list_var_dir" {
        command = "ls /var"
    }
} If I run our tool I get the following error: example.hcl:3,4-9: Unsupported block type; Blocks of type "mkdir" are not expected here. We could update our Task struct and add a block list for "mkdir": type Task struct {
    Name      string       `hcl:"name,label"`
    ExecSteps []*ExecStep  `hcl:"exec,block"`
    MkdirStep []*MkdirStep `hcl:"mkdir,block"`
} but obviously, we would lose the execution order since we have two separate lists. This is not going to work for us. As an alternative solution we could change our configuration and make the Step type a label: task "first_task" {
    step "mkdir" "build_dir" {
        path = "./build/"
    }
    step "exec" "list_build_dir" {
        command = "ls ./build/"
    }
} Let's reflect the configuration change to our structs. type Config struct {
    Tasks []*Task `hcl:"task,block"`
}

type Task struct {
    Name  string  `hcl:"name,label"`
    Steps []*Step `hcl:"step,block"`
}

type Step struct {
    Type   string   `hcl:"type,label"`
    Name   string   `hcl:"name,label"`
    Remain hcl.Body `hcl:",remain"`
}

type ExecStep struct {
    Command string `hcl:"command"`
}

func (s *ExecStep) Run() error {
    return nil
}

type MkdirStep struct {
    Path string `hcl:"path"`
}

func (s *MkdirStep) Run() error {
    return nil
} As you can see we have added a new struct and use it in the struct instead of the Step Tasks ExecStep The struct has an extra field called . This field is required to capture all fields of the actual Step implementation.We will see later how we use the field to decode the fields into our actual Step implementation. Step Remain Remain Lastly, we add a new interface that allows us to run the Step implementation: type Runner interface {
    Run() error
} You can see above that all our Steps implement the Runner interface. Now we have to adapt our parsing code: import (
    "fmt"
    "os"

    "github.com/hashicorp/hcl/v2"
    "github.com/hashicorp/hcl/v2/gohcl"
    "github.com/hashicorp/hcl/v2/hclsimple"
)

var (
    exampleHCL = `
        task "first_task" {
            step "mkdir" "build_dir" {
                path = "./build/"
            }
            step "exec" "list_build_dir" {
                command = "ls ./build/"
            }
        }
    `
)

func main() {
    config := &Config{}
    err := hclsimple.Decode("example.hcl", []byte(exampleHCL), nil, config)
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
    for _, task := range config.Tasks {
        fmt.Printf("Task: %s\n", task.Name)
        for _, step := range task.Steps {
            fmt.Printf("    Step: %s %s\n", step.Type, step.Name)
            // The actual step implementation 
            // which implements the Runner interface
            var runner Runner

            // Determine the step implementation
            switch step.Type {
            case "mkdir":
                runner = &MkdirStep{}
            case "exec":
                runner = &ExecStep{}
            default:
                fmt.Printf("Unknown step type %q\n", step.Type)
                os.Exit(1)
            }

            // Decode remaining fields into our step implementation.
            diags := gohcl.DecodeBody(step.Remain, nil, runner)
            if diags.HasErrors() {
                fmt.Println(diags)
                os.Exit(1)
            }

            err = runner.Run()
            if err != nil {
                fmt.Println(err)
                os.Exit(1)
            }
        }
    }
} The parsing does determine the Step type in the switch statement and creates an instance of the Struct. The struct is then the target of which decodes the remaining fields. gohcl.DecodeBody(step.Remain, nil, runner) Voilà, we have an easy-to-extend Task execution engine. Resources Godocs: hcl hclsimple gohcl Others: buildmedia.readthedocs.org/hcl.pdf Source Gists: Example 1 Example 2 Full Source Code package main

import (
    "fmt"
    "os"

    "github.com/hashicorp/hcl/v2"
    "github.com/hashicorp/hcl/v2/gohcl"
    "github.com/hashicorp/hcl/v2/hclsimple"
)

var (
    exampleHCL = `
        task "first_task" {
            step "mkdir" "build_dir" {
                path = "./build/"
            }
            step "exec" "list_build_dir" {
                command = "ls ./build/"
            }
        }
    `
)

func main() {
    config := &Config{}
    err := hclsimple.Decode("example.hcl", []byte(exampleHCL), nil, config)
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
    for _, task := range config.Tasks {
        fmt.Printf("Task: %s\n", task.Name)
        for _, step := range task.Steps {
            fmt.Printf("    Step: %s %s\n", step.Type, step.Name)

            var runner Runner

            switch step.Type {
            case "mkdir":
                runner = &MkdirStep{}
            case "exec":
                runner = &ExecStep{}
            default:
                fmt.Printf("Unknown step type %q\n", step.Type)
                os.Exit(1)
            }

            diags := gohcl.DecodeBody(step.Remain, nil, runner)
            if diags.HasErrors() {
                fmt.Println(diags)
                os.Exit(1)
            }
            err = runner.Run()
            if err != nil {
                fmt.Println(err)
                os.Exit(1)
            }
        }
    }
}

type Config struct {
    Tasks []*Task `hcl:"task,block"`
}
type Task struct {
    Name  string  `hcl:"name,label"`
    Steps []*Step `hcl:"step,block"`
}

type Step struct {
    Type   string   `hcl:"type,label"`
    Name   string   `hcl:"name,label"`
    Remain hcl.Body `hcl:",remain"`
}

type ExecStep struct {
    Command string `hcl:"command"`
}

func (s *ExecStep) Run() error {
    // Implement me
    return nil
}

type MkdirStep struct {
    Path string `hcl:"path"`
}

func (s *MkdirStep) Run() error {
    // Implement me
    return nil
}

type Runner interface {
    Run() error
}

How to Implement your Own Tool Using HCL (bc I Hate YAML)

Go has hard opinions about how you should style and format your code. The big upside of this is that you don't need to spend hours setting up tools like ESLint, Prettier, JSLint, etc. That said, in order to take advantage of the styling and listing tools available in the toolchain, you need a dev environment that makes them easy to use. VS Code - Lint on save I'm currently a fan. I don't like to think about code styling. I like to type a bunch of code with incorrect spacing and press (ctrl+s) or (cmd+s) to save my code and auto-format it. VS Code First, make sure you have the latest version of Go installed on your machine (as of time of writing, 1.14) Next install the Official Golang VS Code Plugin Next open your file in VS Code. These settings can be specific to in a single project, workspace or your entire machine. settings.json Add the following settings: { : , : , : , : { : , : { : }
    }, : } "go.lintOnSave" "file" "go.formatTool" "goimports" "go.useLanguageServer" true "[go]" "editor.formatOnSave" true "editor.codeActionsOnSave" "source.organizeImports" true "go.docsTool" "gogetdoc" If you don't like any of these settings, you can click the pencil icon to the left of the line (assuming you've opened settings.json in VS Code). It will give a dropdown menu with additional options. Why goimports and not gofmt? Simply put, does everything gofmt does but additionally formats import statements. I like that. goimports Not Working? If it still isn't working, you likely need to reload your VS Code window and/or install the missing tools that VS Code is prompting you to install via popups in the bottom-right of the editor. I will do my best to keep this guide up to date. Let me know if it isn't working for you via or the . Twitter Qvault Discord Thanks For Reading Follow us on Twitter if you have any questions or comments @q_vault Take game-like coding courses on Qvault Classroom to our Newsletter for more educational articles Subscribe Previously published at https://qvault.io/2020/06/30/lint-on-save-with-vs-code-official-golang-extension/

 A Few Words on VS Code

The beauty of Go

: tldr Using a basic monorepo (one repository for all services code) project design can make development easier when building many services. Backstory I work for a learning company which has two main goals: Help individuals learn/discover skills relevant to their organization’s needs. Help organizations retain/onboard/train individuals. To fulfill these two goals our company collects, processes, and analyzes tons of data. This data challenge is common among many companies working on the enterprise level. It requires a solid data-pipeline infrastructure which is and while still . There are considerations to consider while building. This blog post will focus only on a high level view of a small portion of this pipeline. fast scalable reliable design Why use Golang? : Go was designed with simplicity in mind. There are only , only one loop (the loop), all code has a common style thanks to , etc… . This simplicity allows for scalability in a team sense. If new team members are to work on applications written in Go it is easier for them to read and understand the code. This increases the size of the pool of programmers available to help with development. Scalability 25 keywords for go fmt : Since Go is a strongly typed language which also has great error handling mechanisms it makes great reliable code. The Go project also has a great race detector tool to help identify possible race conditions. Reliability : Go is . Speed fast Why use services and a monorepo? Scaling out a team is more than just choosing a language which everyone can work on. The code must be organized in ways which allow for easy lookup and modification. This often requires while having . the code to live close to each other well defined responsibilities Well designed monoliths accomplish these tasks, but sometimes stall when design patterns diverge, responsibilities are incorrect, or specific parts of the application are too resource intensive and bring down the whole application. Parts which are resource intensive is why some projects choose to break off code into separate services. Services (or whatever you want to call them) can run into the same problems as a monolith project; however, many services are also split up across multiple repositories which can make it hard for new team members to quickly navigate the project as a whole. Data-processing has a variety of requirements for tasks. Some tasks might require quick turnaround time. Others might receive large batches of data which takes minutes to process. Since the requirements of these tasks vary greatly using services makes sense. There still might be issues, but scaling out individual processes horizontally/vertically based on their individual needs is much easier. The last issue is code proximity. The concept of a can mitigate the proximity issue in certain cases. For the scenario of many Go services often sharing similar packages, the monorepo concept works out quite nice. monorepo (one repository for all services code) Design A monorepo project design will be different compared to a package or small project. It is important to note that these design suggestions are just suggestions. Folder Structure Structures of projects are important for organization. The quicker someone can visualize the project as a whole the faster they can contribute. With the designers have not forced a folder convention so your team can use their ideals and preferences to find a solution. Below is one monorepo example folder structure. Golang ├── Makefile When projects become large and more individuals start contributing code it becomes difficult to enforce everyone to use the same commands. A Makefile can help standardize a nice shortcut list for contributors to use. Here are some tasks you might want to include in your projects: : Builds the binary for your go project and places it in the folder. build bin : Runs tests using specific flags or tools. With Go’s testing package you can also specify test groups if your code base become very large. test : Runs a deploy script or trigger to deploy a specific project. It usually makes sense to keep your build and deploy tasks separate. Your Makefile can always specify a specific order to run them. deploy : Cleans out old build objects and artifacts. clean cmd Folder The cmd folder is meant to hold your application entry points (main funcs). These entry point files are responsible for setting up and configuring each application. pkg Folder All internal packages which do not make sense as a standalone package should be located in a pkg folder. The organization of files within this folder will depend on your organization. Here are some general tips. Keep the in mind while organizing. KISS principle Teams will often be tempted to design projects in familiar language folder styles, but it is important to remember Go is the language and having a package for every data model might not make sense. Having named or are not clear to developers unfamiliar with your code base. If the code base becomes large enough developers might even forget what functions are held in these generic packages and end up adding duplicate functions. generic packages utils misc Splitting up a single package into separate files with good names often helps organization, but having 20 files which are only 20 lines long probably doesn’t make sense and will most likely annoy developers. Sometimes one file is enough. Designing a package which holds all error types might seem like a good organizational tactic, but it increases package entanglement and forces developers to jump file to file. bin Folder For many projects the folder is responsible for holding binary files. So it makes sense to store any binary files within this folder. Especially our compiled projects. bin scripts Folder Having a folder dedicated to scripts works well when paired with a Makefile. Teams can have complex deploy scripts which trigger multiple actions and keep the code separate from the Makefile. This keeps your Makefile clear and simple. docs Folder Every Go project should use methods, but there are benefits to making documentation which is not contained in your Go files. Having higher level docs can be tailored to users who do not care to see the inner workings. They also can house deployment processes, contributing guidelines, and other information which wouldn’t make sense to contain within the packages documentation. Godoc’s Conclusion This article was written as a small opinion piece on project design. It was meant to give suggestions not force standards. Feel free to disagree or share opinions or thoughts. Check out if you are interested in learning more about our company. Pathgather Links: Picture from: http://www.pcanimalcontrol.com/gopher-control-removal.php

AODOCS

aodocs.com

-- employees

Since n.d.

COMPANY RANKING

AODOCS

EVERGREEN INDEX #744

Representing this company? Click here to claim and customize this page!

AODocs WIKI

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

AODOCS

aodocs.com

-- employees

Since n.d.

COMPANY RANKING

AODOCS

EVERGREEN INDEX #744

RELATED COMPANIESRANK

STORIES ABOUT AODOCS

Representing this company? Click here to claim and customize this page!

AODocs WIKI

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