I am working on a side project and was looking to see if there are any API's that given a vehicle's year, make, and model, it would show sort of a timeline for that vehicle's maintenance. For example, how often to change oil, when to change transmission fluid, etc.
Does anyone know of any API's that have this sort of information? I was going to end up trying to create a basic timeline that works with every car, but I thought it would be better to be more accurate with the chosen vehicle model.
Related
I'm attempting to clone gmx.io. I understand most of the on-chain and Dex concepts, but I'm stumped on how to establish an off-chain. Keepers they did not opensource the code for that, so could you kindly assist me in determining what the specific usage of the keepers was and how I would implement keepers?
I've included some relevant articles below.
https://gmxio.gitbook.io/gmx/contracts
https://gmx-io.notion.site/gmx-io/GMX-Technical-Overview-47fc5ed832e243afb9e97e8a4a036353
https://medium.com/perpdex/gmx-research-9da560f1e447
https://liamhieuvu.com/how-gmx-limit-order-and-long-short-work
I tried developing a basic listener that monitors the price of the token 24 hours a day, seven days a week, and temporarily stores all orders, and when any order limit price matches the asset price, I call the smartcontract function to start a position.
But it isn't working or performing as expected, so I wanted to find out exactly what I needed to accomplish, what tools and services I required, and how I would implement it in accordance with the standards.
I am currently working on a project where I want to build a model which can detect and track people with a unique ID. The main issue is when a person leaves the frame and comes back after some time. Currently, I am working with yolov4 and Deepsort to detect and track. But it is failing in this situation.
Please suggest some approach where we can do detection, reidentification and tracking of people or cars or any other object.
Thank you :)
Although YOLOv4 can detect people in an image/video stream, I think it might be too general in your case. When a person leaves the frame and comes back, ideally the model should remember seeing that person before.
One way to tackle this is to train on images of the people you want to detect.
E.g. in a system like yours, you could take multiple images of the people you want to track from different angles and label them using their unique identifiers. Afterwards you could train the model using this data (for your downstream task). This will ideally give more specific results for detecting and tracking people with their unique identifiers as opposed to the general people detection when using YOLOv4 as is..
That said, I understand that taking lots of images of people may not be practical in certain scenarios. In that case you may want to look at techniques that produce accurate results with minimal data such as domain adaptation (https://arxiv.org/abs/1812.11806). However in an application for tracking and detecting people, I'm assuming you want minimal misclassifications.. Hence you could say it's always a tradeoff.
You can find out more about dealing with lack of data in this article: (https://www.kdnuggets.com/2019/06/5-ways-lack-data-machine-learning.html)
However I think this is a better place to start for a re-identification model: (https://github.com/KaiyangZhou/deep-person-reid)
It has ample documentation to get you started..
In reference to this infographic about the data science industry.
I have a question about the relationship between HTML and data analysis!
Is there really a relationship between them?
If so, what is this relationship?
How can we use HTML in data analysis?
HTML is not a programming language. It is a document markup language. It really can't do much on its own. It can present results but offers limited interactivity. I think when people say HTML they really mean the combination of HTML/CSS/JavaScript.
With JavaScript added, you could technically code anything, though, in practical terms, it's only going to be suited for so many things due to performance concerns and the like.
As Mark_M said, it's mostly used for the presentation layer. This is especially important in the context of business. Let's go through an example. Say you build a model that predicts which of your companies product an individual customer or prospective customer would be most likely to purchase. What are you, as the analyst, going to do with that information? Do you care personally that Sally M wants to buy widget A and Frank R wants to buy widget B? Sure your company cares. Sure your pay is loosely based on the performance of the company. But you have plenty of other things to analyze. So now what?
Do you know who really cares about that information? The Sales Team. That's their whole job. Their pay is based on commission. They know how to act on that information. You let the sales team know this, they do their thing, you get your own performance pay, the company does well, everyone wins.
Now, how do you tell the Sales team this information? Do you let them call you every time they need a lead? Do you give them some sloppily written code in MATLAB or a command line Python client? Do you give them the math equations and tell to figure it out?
Now, remember, a lot of the sales team are not very technically savvy. Even if they sell technology, they barely know enough about it to sell it. The Sales team doesn't know what a -345 error code means. They interface with the customer and ask a member of the support or engineering team for help as needed. The sales team can barely handle the basics of Excel. I would bet you that 90% of the sales team doesn't even know what a "for loop", but that's ok, you don't know how to get that guy on the fence to hand over his signature. People have different strengths.
So what now? You need Bob the salesman to have all the information he needs without bothering you while you code up the next analysis. If you make it too hard, they won't use it. That's just the way life works.
Do you know what's really easy to use? Web applications. Bob the salesman can figure out any web application, especially if it's well designed. So you code up your analysis in the form of a web application. Maybe you have a web design team at your company to redesign your web application, to make it more user-friendly, but they don't know the details of your model. You must code up a prototype web application to allow other people to run and use your model.
Data analysts and data scientist (some at least) are expected to write prototype web applications. You might hear these things called "dashboards." It isn't very hard actually. There are technologies such as R Shiny and Bokeh to make it easy peasy, at least compared to the harder parts of your job.
The application, of course, might not make it out to the general internet, or it might. But it could very well at least make it onto your company intranet. The old way of doing things is companies keeping all their analysis in Excel files and passing those around. The new way is web applications on the intranet.
Your models are totally useless if no one turns them into actionable information and then actually acts on them. The company isn't paying you to build models. They are paying you to tell them what they should do to make more money. You must make it easy enough for them to achieve that.
That's the relationship. In short, it's the presentation layer, ha.
I'm working on an e-commerce type web application and need to somehow handle calculation of shipping costs. Some rules I've found:
Free shipping
Free shipping with minimum purchase
Free shipping within a certain geographic area
Flat rate shipping
Flat rate + set amount per product
Various rates depending on speed of shipping (shipped immediately and/or how soon it gets to customer)
Based on height, width, depth, weight + shipping distance
Based on rates of various shippers
... and so on.
Any suggestions how to tackle such a problem?
I suggest you take a look at some available open source ecommerce solutions. There are a LOT of them and each one takes a stab at doing exactly what you are trying to do. If it is schema design you are after I wouldn't limit your searches to just MySQL - as long as it contains a relational database it should be easy to dig into the design. I'd take a look at nopcommerce to name just one...
Create a framework where your eCommerce system accepts modules that define shipping rules (and interfaces and calculations, etc). Design it such that you expect these modules to be able to provide all those functions. Let the end users decide which modules to use based on their own needs, as which shipping rules to use is a business decision and not a technology one.
A little background: I have the opportunity to present the idea of a public API to the management of a large car sharing company in my country. Currently, the only options to book a car are a very slow web interface and a hard to reach call center. So I'm excited of the possiblity of writing my own search interface, integrating this functionality into other products and applications etc.
The problem: Due to the special nature of this company, I'll first have to get my proposal trough a comission, which is entirely made up of non-technical and rather conservative people. How do I explain the concept of an API to such an audience?
Don't explain technical details like an API. State the business problem and your solution to the business problem - and how it would impact their bottom line.
For years, sales people have based pitches on two things: Features and Benefit. Each feature should have an associated benefit (to somebody, and preferably everybody). In this case, you're apparently planning to break what's basically a monolithic application into (at least) two pieces: a front end and a back end. The obvious benefits are that 1) each works independently, so development of each is easier. 2) different people can develop the different pieces, 3) it's easier to increase capacity by simply buying more hardware.
Though you haven't said it explicitly, I'd guess one intent is to publicly document the API. This allows outside developers to take over (at least some) development of the front-end code (often for free, no less) while you retain control over the parts that are crucial to your business process. You can more easily [allow others to] add new front-end code to address new market segments while retaining security/certainty that the underlying business process won't be disturbed in the process.
HardCode's answer is correct in that you should really should concentrate on the business issues and benefits.
However, if you really feel you need to explain something you could use the medical receptionist analogue.
A medical practice has it's own patient database and appointment scheduling system used by it's admin and medical staff. This might be pretty complex internally.
However when you want to book an appointment as a patient you talk to the receptionist with a simple set of commands - 'I want an appointment', 'I want to see doctor X', 'I feel sick' and they interface to their systems based on your medical history, the symptoms presented and resource availability to give you an appointment - '4:30pm tomorrow' - in simple language.
So, roughly speaking using the receptionist is analogous to an exterior program using an API. It allows you to interact with a complex system to get the information you need without having to deal with the internal complexities.
They'll be able to understand the benefit of having a mobile phone app that can interact with the booking system, and an API is a necessary component of that. The second benefit of the API being public is that you won't necessarily have to write that app, someone else will be able to (whether or not they actually do is another question, of course).
You should explain which use cases will be improved by your project proposal. An what benefits they can expect, like customer satisfaction.