Get the most recent info and news about Licenseware on HackerNoon, where 10k+ technologists publish stories for 4M+ monthly readers.

Licenseware | Oracle licensing | Identify false and accidental usage, prevent audit exposure and fix issues before they become real problems.

Licenseware

licenseware

One of the first benefits of SAM is that it gives you a clear and accurate picture of your software landscape. You can use SAM tools to scan your network and discover all the software assets you ...

How do you leverage SAM insights to improve your IT performance and security?

HackerNoon Reporter: Please tell us briefly about your  background. Speaking for myself, Cirpian, and Chris, we’ve been working in the software industry for over a decade now, having played a variety of roles related to IT asset management. I’ve had various roles with a focus on software asset management, data analytics, and software development. Walked in the shoes of an analyst, auditor, advisor, and software engineer, and was involved in building Software Asset Management (SAM) tools amongst other data-focused projects. Ciprian has been dealing with all things technical in software asset management. He’s been involved in the design and creation of several SAM tools. He has a passion for business automation and is always tinkering with technology trying to find better ways to make software work for companies. Chris has been working in SAM and software sales for over 7 years. Along with selling solutions, he spent time delivering them, specifically focused on Microsoft optimization and remediation, and assisted in audit defenses. What's your startup called? And in a sentence or two, what does it do? We’re Licenseware, the first open app ecosystem for software license management. We build technology that helps companies save or reduce their software cost as well as manage the risk associated with licensing. What is the origin story? Ciprian, our CTO, is the original founder. Having built several SAM tools in the past for other companies, he thought it was time to build one of his own. He wanted to channel his passion for software engineering into something useful, and also learn a thing or two in the process. He noticed that all SAM and ITAM tools in the market follow a similar monolith-type approach. And they are all closed. He thought that this is an outdated way of building software and a rigid business model. He built a prototype and showed it to a few people in his network. When he showed me the tool and explained the idea, it instantly clicked. It was the tool that I always wanted to use when I was a consultant or analyst in my previous jobs. It was also the change I wanted to see in the industry. After some back and forth and a few coding sessions, we eventually became more serious about it and it became more than a hobby project. We ended up pitching for the first time at a startup event, where the product was very well received, with a “Best Innovation” award. Shortly after, we got sucked into the startup scene and we ended up closing a pre-seed round. In 2020, we launched the first version of the product and started building a team. While Ciprian and I mostly focused on building the product and a development team, we felt we needed someone in the founding team with sales and marketing experience. The first person that came to mind was Chris, who’s been connected with us on LinkedIn a few years back. His posts and unique approach to marketing and sales caught our attention. Chris is a different kind of sales guy, and we’ve built a different kind of tool. We managed to convince him to join eventually, the idea also clicked with him instantly, and shortly after, we raised a seed round and started scaling. What do you love about your team, and why are you the ones to solve this problem? We’re a fully remote and distributed team. I really love this clash of cultures, and how we can leverage talent and ideas from all over the world (we’re now in the UK, Spain, Romania, India, Tunisia, Kenya, Turkey, Netherlands, Denmark, etc.) to build a great product. What brought us together was our passion for data and software engineering, but what made us stick together was our values. There’s a very strong cultural alignment in the team, even though we come from very distinct backgrounds. Aside from the obvious qualifications, I think what makes us the right crew for the job, is that we as a founding team, have been directly dealing with the problems we’re now solving with our technology. If you weren’t building your startup, what would you be doing? If I wouldn’t be building Licenseware right now, I would be building some other kind of software, probably. I was a software engineer prior to co-founding Licenseware. It was always on my bucket list to start a company, so I might have gone down the startup road anyway.

Startup Interview with Alex Cojocaru, CEO of Licenseware

240 Stories To Learn About Startups Of The Year

95 Stories To Learn About Startup Founders

283 Stories To Learn About Founders

198 Stories To Learn About Founder Stories

I love things to be organized and easily managed. Secret data in code is no exception. Previously I wrote a guide . And now, I want you to look at one more solution - . how to use AWS Secrets manager AWS Systems Manager Parameter Store It provides a secure and hierarchical storage and management system for secret data like passwords, secret parameters, licenses, etc. You can avoid routine with handy-managed secret files, which you should share with every team member and add to every Jenkins Job. Just add them to centralized storage and set up retrieving via AWS API. The great benefit of Parameters Store is that you can save any piece of data instead of AWS Secrets Manager, where you can choose only a particular format. Let's configure some secrets and see how it works in practice. Imagine that we want to store licence.xml for some library. <LICENSEFILE>
    <FEATURE NAME="MyFeatureName"> 
        <SETTING MAJOR_VERSION="1"/>
        <SETTING MINOR_VERSION="0"/>
        <SETTING END="2018-01-01"/>
        <CLIENT_HOSTID>
            <SETTING IPADDRESS="123.123.123.123"/>
            <SETTING USERNAME="john"/>
        </CLIENT_HOSTID>
    </FEATURE>
</LICENSEFILE> Find the Parameter Store and open the main page. Follow the "Create parameter" button and go to the configuration page. Type a secret name and choose type "SecureString." Put secret data to the value field and follow "Create parameter." That's all, secret created! To make it accessible for target users need to grant permissions with the policy that allows reading params: {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ssm:GetParameter",
            "Resource": "*"
        }
    ]
} And now, let's get it from code. Add SSM dependency to your project, create a rest client, perform a get request with decryption, and use the received secret. <dependency>
   <groupId>com.amazonaws</groupId>
   <artifactId>aws-java-sdk-ssm</artifactId>
   <version>1.12.186</version>
</dependency> AWSSimpleSystemsManagement client = AWSSimpleSystemsManagementClient
       .builder()
       .withCredentials(new AWSStaticCredentialsProvider(new BasicAWSCredentials(accessKey, secretKey)))
       .build();


var getParameterRequest = new GetParameterRequest()
       .withName("licence.xml")
       .withWithDecryption(true);
String license = client.getParameter(getParameterRequest).getParameter().getValue();

LicenseReader.read(license); This way, you can store and retrieve any data that can be deserialized from string to any object you might be interested in. Conclusion Parameters Store is a secure and scalable secrets management service with no servers to manage. In the case of different types of secret data, it looks like a universal solution for all of them. That is a great way to manage stricted things in your project.

AWS Parameters Store for Test Automation Project

In this article, I'll explain how to generate an API blueprint instantly using SwagGo in Golang. API blueprint is a document that contains a bunch of API endpoints, it's slightly the same as documentation but with less description. It allows another programmer to read and see all the available endpoint and try it out with sandbox feature. Swagger is one of the most used API blueprints right now, it's available in free but limited usage. if you wanna use the free credit, you need to understand YAML notation, you can read the example notation in Swagger official documentation. But again, it's really hard and takes an expensive time to arranges all the notation to achieve a good API blueprint. Fortunately, there are tools in Golang that allow us to generate the YAML notation and automatically generate the blueprint page with only using markup notation, and it's FREE unlimited for self-host, insane right? SwagGo tools are available , the documentation is very clear, but in my experience, I need a lot of time to totally understand how to use it. here I wanna explain what I got and what I have been implemented. here These tools support familiar frameworks, such as and but in this tutorial, I would like to use default standard Go web server. echo gin, Prerequisites macOS Big Sur Shell Zsh Golang Version 1.14 http-swagger You can also use Linux,  but if you are using windows, it might be has a different result and experience. first thing first, you need to install SwagGo Generator. $ go get -u github.com/swaggo/swag/cmd/swag after installation success, check the availability by using bellow command $ swag --version
swag version v1 .6 .7 then, move to your project, in my example, I will make a simple project that contains several files. in order to use these tools, you need files at least main.go run command to initiate SwagGo files in your root project. $ swag init / / : : Generate swagger docs.... / / : : Generate general API Info, search dir:./ / / : : create docs.go at docs/docs.go / / : : create swagger.json at docs/swagger.json / / : : create swagger.yaml at docs/swagger.yaml 2021 02 02 22 52 14 2021 02 02 22 52 14 2021 02 02 22 52 14 2021 02 02 22 52 14 2021 02 02 22 52 14 right now, your project will contain newly added swagger files and folders. $ ls -al
total drwxr-xr-x jauharibill  staff Feb : .
drwxr-xr-x jauharibill  staff Feb : ..
drwxr-xr-x jauharibill  staff Feb : docs
-rw-r--r-- jauharibill  staff Feb : main.go 8 4 128 2 22 52 56 1792 2 22 47 5 160 2 22 52 1 80 2 22 52 in docs folder contains these files. $ cd docs
$ ls -al
total drwxr-xr-x jauharibill  staff Feb : .
drwxr-xr-x jauharibill  staff Feb : ..
-rw-r--r-- jauharibill  staff Feb : docs.go
-rw-r--r-- jauharibill  staff Feb : swagger.json
-rw-r--r-- jauharibill  staff Feb : swagger.yaml 24 5 160 2 22 52 4 128 2 22 52 1 1397 2 22 52 1 84 2 22 52 1 45 2 22 52 there are that used to renew and generate the following and file. you don't need to modify these file, just ignore it and they will changes when you run the swag command. I will explain it below. docs.go swagger.json YAML after knowing directory structure, then we will write minimalis code like below. in main.go write these code : main ( _ httpSwagger ) {
	http.ListenAndServe( , router())
} {
	r := chi.NewRouter()

	r.Get( , HelloWorld) r
} response {
	Message Status } { response response

	response.Message = response.Status = payload, _ := json.Marshal(response)
	w.Write(payload)
} package import "encoding/json" "net/http" "github.com/go-chi/chi" "GOLANG-API-BLUEPRINT/docs" "github.com/swaggo/http-swagger" // main func main () ":8080" // router . func router () http Handler "/" return // default response type struct string `json:"message"` bool `json:"status"` // HelloWorld Controller func HelloWorld (w http.ResponseWriter, r *http.Request) var "Success Retrieve Data" true above code is a simple webserver build with golang, it will represent REST API. first thing first, we will try to put identity for our REST API. Put markup comment that already define by SwagGo above main method. {
	http.ListenAndServe( , router())
} // @title EXAMPLE REST API // @version 1.0 // @description This is a sample server celler server. // @termsOfService http://localhost:8080/terms/ // @contact.name Bill Tanthowi Jauhari // @contact.url http://localhost:8080/support // @contact.email bill@localhost // @license.name Apache 2.0 // @license.url http://www.apache.org/licenses/LICENSE-2.0.html // @host localhost:8080 // @BasePath / // @query.collection.format multi func main () ":8080" Run command swag to generate markup docs into yaml and json Swagger. 2021/02/03 20:58:36 Generate swagger docs....
2021/02/03 20:58:36 Generate general API Info, search dir:./
2021/02/03 20:58:36 create docs.go at docs/docs.go
2021/02/03 20:58:36 create swagger.json at docs/swagger.json
2021/02/03 20:58:36 create swagger.yaml at docs/swagger.yaml $ swag init -g main.go above command will update json and yaml files in docs folder. if you want to see the result, you can put that generated notation into swagger hub.  you can also self host your blueprint, simply add swagger router. {
	r := chi.NewRouter()

	r.Get( , HelloWorld) r.Get( , httpSwagger.Handler(
		httpSwagger.URL( ),
	)) r
} // router . func router () http Handler "/" // swagger self host router "/swagger/*" "http://localhost:8080/swagger/doc.json" return after adding swagger router, you can see the blueprint at http://localhost:8080/swagger/index.html cool, the first markup swagger that we write before already published. but the thing is there is no endpoint available yet. to put endpoint blueprint, you can put more markup into targeted method, for example : { response response

	response.Message = response.Status = payload, _ := json.Marshal(response)
	w.Write(payload)
} // GET Hello World Message // @tags Message // @Summary show message hello world // @Description show message hello world // @Accept  json // @Produce  json // @Success 200 {object} response // @Failure 400 {object} response // @Failure 500 {object} response // @Router /  [get] func HelloWorld (w http.ResponseWriter, r *http.Request) var "Success Retrieve Data" true Run swag command again, then you can see the result. finally the endpoint blueprint available, inside the endpoint there is a description and a lot of REST API information. also the best part is, you can try the endpoint directly from that page, klik "try it out" button and execute the endpoint. Finally, we already make a REST API blueprint using SwagGo. you can modify and improve all the markup by learning deeper from the documentation . Reach me out at my social media, Good luck! here Also published on: https://www.bill.web.id/2020/09/automatic-api-documentation-swagger-in.html

How To Generate API Blueprint using SwagGo

Sometimes I notice that I have just wasted one hour or so because of some bug in my , or something that I did wrong. When that happens I try to step back, understand what I did and try to come up with a change in my way of working that will prevent it from happening again. code The funny thing is that over the years I’ve gathered several guidelines that I use, and sometimes when my teammates question me about them, I actually don’t remember the . I just that it’s a best practice and that I should follow it. But on this article I tried to go through several of those practices that I follow and tried to justify them. whys know There’s also a , mostly related with testing, readability, and style. Using these patterns could turn a project into something that . part 2 with more patterns no one wants to work at Exceptions without context Whenever I see code throwing an exception without additional information, I frown. Something like: def operate  raise "Ups something went wrong" if damage?end With the exception we get a stack trace and the information that something was wrong. But most of the time we lack the context to understand the problem. Data like the current user, the current object’s data, what were we trying to accomplish and what were we expecting. As a rule of thumb all custom exceptions should have data describing what was happening. def operate(operator)  raise OperationDamagedException.new(self, operator) if damage?end This will allow us to have much more information. When something goes wrong it’s useful to have information to troubleshoot. In several languages (Ruby, JavaScript) there isn’t much attention to logging, while in others logging is a very important thing (Java). For example, in Java I was used to see code like this: try {   // ... } catch (final IOException ex) {  LOGGER.error("Something bad happening and here you have info.", ex);  throw new BusinessException(ex); } And this is actually much better. But the problem is that we’ll have to search the logs for when this happened and that may not be easy. Actually, it may actually be very complex to get the logs if we don’t have access to the production environment. But we always get the exception. So I always push for better error reporting, and try to sell logging mainly for app’s behaviour. Constructors with lots of default arguments This is something that I have seen in Java code bases. Java code and tooling allow for easy refactor and sometimes that allows for this kind of . For example, imagine that we have a POJO that we use in many places, and on unit tests we start having: pattern @Test public void test1() {  final Entity entity = new Entity(1, null, null, false, "", Optional.empty());  // ... }

@Test public void test2() {   final Entity entity = new Entity(1, null, null, false, "", Optional.empty());   // ... } 

// And so on When we change the arguments in any way we’ll need to update all those places where we just wanted a dummy . This is code that may be easy to refactor but is not . Entity easy to change We should instead have something like: class Entity {   public static Entity empty() {     // Even better if this can be a static immutable instance    new Entity(1, null, null, false, "", Optional.empty());   }} Now if we change the ’s’ constructor, all code that uses it doesn’t need to be changed. Note that we may have a more way of doing this, by creating a class. And that builder class could have that method. Entity “Java-ish” builder “empty” Honestly this may be my biggest complaint about coding in Java. Having to create those builder classes is always cumbersome. Yes, our IDE may help, but if we want code that is properly documented we still need to go and take care of all the builder’s methods. Anyway, we could make this more simpler by just creating a constructor with no parameters. But whatever the approach we take, a question remains: are we adding code just for tests? And yes, we are. We are changing the class’s API just because of tests. Now on this scenario I’d rather focus on , and wouldn’t mind. testability But there are better options, mainly by creating a factory class just for tests, that could use some logic, for example. faker Arrays of statuses This is mostly common on languages that don’t have s. It goes like this: enum class Invoice  validate :status, inclusion: { in: [:draft, :sent, :paid] }end

def pay!(invoice)  return if invoice.status == :paidend The problem is that these statuses start to leak. We’ll start using them by name on several places. They are prone to typos and it’s hard to maintain. Imagine that you add a new status. It’s better to abstract these concepts on specific constants. :rejected class Invoice  STATUSES = ([:draft, :sent] + PAID_STATUSES).freeze   PAID_STATUSES = [:paid].freeze 

  validate :status, inclusion: { in: STATUSES }end

def pay!(invoice)  return if invoice.status.in?(Invoice::PAID_STATUSES)end Now the class is the owner of the concept and it’s easy to change without being concerned about code that uses it. Invoice statuses But we can also do better. Because in the future we’ll have this change request: We want a rejected status, but just for Portuguese speaking users. Now just constants won’t do the trick, and we have constants all over the place. We can refactor, but it would be better to prepare for this from the start. class Invoice  STATUSES = ([:draft, :sent] + PAID_STATUSES).freeze  PAID_STATUSES = [:paid].freeze 

  def self.statuses(context = {})    return STATUSES + [:rejected] if portuguese?(context)    STATUSES  endend This way we have a good default, but can augment it with additional information. High level classes with closed API I’m talking about classes that represent services, interactors, use cases, and overall higher level interfaces. Classes that form an API that is public and used as boundaries to other layers. In dynamic languages we may have arbitrary arguments and that’s great for maintainability. If we define a strict API we’ll have the following scenario: class ProcessPayment  def initialize(account, amount)    # ...   end 

  def call    # ...   endend

ProcessPayment.new(account, 10.0).call Imagine now that this class is used all over the place, that we have a library with it and even external clients use it. And now we want change it’s API in a non breaking way. We want to add the amount’s currency. We could just add another optional argument. But what if we want to add data for an invoice? Another optional argument? We may end up with: class ProcessPayment  def initialize(account, amount, currency, invoice_data, include_taxes)    # ...   end end 

ProcessPayment.new(account, 10.0, :EUR, { vat: 1234 }, false).call This will be very hard to maintain. And when we’re at this situation, if we want to change the order or the semantics of an argument, it can be complicated without a breaking change. We could always create additional factory methods. But that’s more code to maintain and test. Another options is to assume that the argument list will be changed. class ProcessPayment  def initialize(args)    # ...   end end 

ProcessPayment.new({  account: account,   amount: 10.0,   currency: :EUR,   invoice_data: { vat: 1234 },   include_taxes: false }).call This is much more readable and easy to maintain. But we’ll need to consider proper documentation and validations. In a typed language this could be a POJO just for the arguments. Not using an hash for optional parameters This is related with the previous pattern. Sometimes we have methods that have some options and we just add more parameters for them. I actually do this some times and I usually regret it. Example: function getSettingsFor(user, bypassCache) {   // ... } const settings = getSettings(user, true); Seeing that there is already a smell. Because we’ll never know what that does unless we read the docs. For these scenarios is much better to augment the function to receive options: true boolean function getSettingsFor(user, options) {  // ... }const settings = getSettings(user, {   bypassCache: true,   includeHolidays: false }); 

// Or just: const settings = getSettings(user) Using a hash instead of a typed object Following on the previous example, if we’re using a strongly typed language, using a map/hash/dictionary may actually be bad for maintenance. We may start to get things like: final Map<String, Object> options = new ImmutableMap.Builder<String, Object>()  .put("bypassCache", true)   .put("includeHolidays", false)   .put("ignore", ImmutableList.of("Profile", "Account"))   .build(); 

final Settings settings = getSettings(user, options); Java developers may already be getting the shivers just by seeing raw s. In this scenario we could create a POJO with all those information, and it will be much more splicit. String final Options options = Options.Builder()   .setBypassCache(true)   .setIncludeHolidays(false)   // ...   .build();

final Settings settings = getSettings(user, options); It’s interesting that I find this typed approach better on typed languages, but for example in Clojure I don’t miss it. Having a data map with the information and a spec to validate that I’m getting what I expect would be preferable for me. Easy access to heavyweight functionalities This is very common on Rails applications. ActiveRecord makes it very easy to get data and persist it on the database. And you can use it everywhere. For example, you could see something like this on a simple property of a PORO: def can_get_drivers_license?  requirements = self.user.country.driver_settings.license.requirements  age > requirements.min_age if requirements.present? age >= 18 end I added a big on purpose. Without knowing the code, I don’t know if that will perform one query with several joins, or if that will perform several queries. Each object may be fully loaded, even if we don’t need it. That code will also get a connection from a pool and connect to somewhere. train There are a lot of things going on. And when that happens, it means that the probability of changing something is bigger and it will be hard to maintain this code. In these scenarios I actually advocate for having some constraints. For example, if we have a class that performs queries that receives the connection pool, we wouldn’t be able to use it here, because we wouldn’t have a connection. This would force us to think about our data model and where to fetch the required data. And it would make the a method, that is very easy to test. can_get_drivers_license? pure def can_get_drivers_license?(requirements = nil)   age > requirements.min_age if requirements.present?  age >= 18 end It may be fast to use ActiveRecord but we need to consider the cost of doing so and try to minimise the dependencies we have on it. Big methods There is a rule that says that . This would be harder to accomplish on some languages. And while it might bee too extremist, I already felt the need to enforce it. each method should only have 5 lines But the main point is that we should split things in smaller methods/functions, preferably . For example, I’d argue that most code in a could be a specific method. This can be cumbersome. We’ll need to extract it, and write documentation for it, and add a test. Example: pure branch function operate(users) {   return users.filter(user => {     return user.isSomething && user.isReady;   }) } Against: function isUserReasy(user) {   return user.isSomething && user.isReady; } 

function operate(users) {   return users.filter(isUserReady); } This is much more easy to read and to change. Having communicates directly what that line is doing. We may have simple logic inside the lambda, but we will still need to read, parse and interpret that in our minds And sometimes it’s not that easy to really what’s happening. filter(isUserReasy) understand Tightly coupled code Code that more than it should is very hard to change and adapt to change requests. Consider for example a very common thing in Rails applications: the ability to send an email. knows easily def process_order   # ...   UserNotifier.order_placed(user.email, order).deliver_later end To understand the problems of this line that seems so innocent, let’s consider some change requests. The first one is: . users can define in preferences what emails they’d like to receive Now we’d have to go to places where we user mailers and we’d need to have the user preferences somehow, that we might not even have. We should obviously now create an abstraction that handles emails and hides those details. all Then another change request: . Marketing and product teams want ownership on the emails and want to build the templates and manage everything. For that they have an app that receives events, and then they can do everything by themselves. we won’t do emails anymore, we’ll use a tool for that Ok, so now we have to convert all those mailer calls to something like: def process_order   # ...   publish(:order_created, { user: user, order: order }) end And we can create a nice for this and have everything decoupled. But this refactor may be painful. What data does used? We don’t know. We’d have to go to that method and associated template and see if somehow we also need to send information that we’re not expecting. event bus UserNotifier.order_placed This is a simple scenario where coupling doesn’t seem that problematic. But from experience, but be very troublesome to refactor. Several conditions or loops that mutate variables I think this is the recipe more close to the concept of spaghetti code. Basically because when you start this way, it will be harder to step back and refactor. And you’ll have new changes just following that format and things get messy. let status; let error; if (condition1) {   status = 404;   error = "Error 404 detail"; } else if(condition2) {   status = 403;   error = "Error 403 detail"; } else {   if (condition4) {     status = 402;     error = "Error 402 detail";   } } 

// use status and error This tends to get big, and very hard to maintain. Usually whenever we have a variable being mutated we should be aware and check we if really need that. The amount of variables available and if they can be mutated contribute a lot to code that is harder to maintain. Switch logic Sometimes has a bad rep. But I find it useful on several occasions. I believe the biggest problem comes from using a to process logic. switch switch switch(operation) {   case 'add':     validate();     performAdd();     break;   case 'sub':     validateMinus();     performSub();     registOp();     break;   default:     error(); } When we have this, we know that several things will happen: To change this code we may actually need to read the full method for context It’s not easy to find the spot to change What happens when we need to change several branches? It might be useful to add other things here that are similar to , but not quite the same. But because we already have context prepared, we just copy paste and go on. operation This will get bigger and bigger It’s very hard to get the full picture and understand changes. We could use an hierarchy with polymorphism or a map from to function. By splitting the logic we can have a better view of the global picture, while also being able to dive in a specific operation logic. operation Summary Writing code that is easy to read and change is very hard. We usually don’t think about that because we’re focus on the moment and want to build something. There are some practices and patterns that can help us to write better code by default, on the first try. But we need to always be practicing and trying to improve our coding skills. Originally published at engineering-management.space on May 8, 2018.

Stories, News & Mentions about LICENSEWARE

Licenseware’s Stories on HackerNoon

Licenseware's News & Mentions