I'm not sure if this is the exact place for this question, but I saw that other Altium questions had been posted here.
My team is using Altium to work on this project, but not all of us are familiar with Altium. In fact, really only one team member has the skills to do the bulk of the work.
Setting aside the issues of cross-training, etc., the rest of us want to do our best to further the work. To that end, can Altium accept CSV files? Like, if we had a CSV of the BoM for a PCB, could we import that so that we don't have to manually input all of the desired information into Altium?
Additionally, are there other areas where we could use CSVs? Like, could we import a schematic that was generated by another piece of software?
Any help would be greatly appreciated.
I suspect you cannot use CSV files without scripting. However, there are quite a many components available. Unfortunately, they are not consistent, and some modifications are needed before saving them to your own library.
You can import schematics (and layouts) from some other sw vendors. File>Import Wizard. Some of them require external license, and format can be fixed. Check Extensions and Updates to make sure you have needed plugins available.
I am working with a back end developer who has popped up a REST interface to ship me data in JSON format. Question 1: "Should we include some sort of header that states a data format version?". Reason I am asked is that I want to make sure we can control the structure of the JSON data. Question 2 am I being silly in asking this, the examples I am seeing of JSON don't seem to do this.
It's a common enough request if you need the interface to that REST interface to be stable.
Once that REST API is published, both you and the back-end developer have to figure out what works best for the two of you (and, if there are any, other consumers of that API) when that REST API needs to change in a way that breaks the interface. If the both of you are able to change at the same time, then great. There may not be any need for explicit versioning.
However, from your question it sounds like you need the interface for that API to remain stable. In that case it may benefit the both of you to have some sort of versioning built in. That way the backend developer can evolve their API without worrying about breaking your app, and you can rely on a stable interface to that API.
In that case, there are (AFAIK) three approaches, one of which is the header you described:
A version in the Url
A version in its own request header
A version in the Accept header
Here's a a blog post (written from the perspective of the back-end developer) that talks through some of those approaches: https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/
Such as this api here: http://www.omdbapi.com/
Do they just parse the whole website's HTML and save fields on their own database?
What is a good design, programming-wise?
My simple java developer mentality says this:
1 - Use jsoup (or any other html parsing library) and save the data frequently.
2 - Create restful services that return json, such as "searchByMovieName()", "searchByActor"
3 - Make the services public
Is it simple as that?
It can be, yes.
You can also fetch the pages and scrape the data in real-time (as people call your API). It'll be a little slower but there's less overhead for you and you don't need to worry about stale data.
IMDB also offers files you can use directly: Alternative Interfaces
We have a pretty large React-Redux based web app. In the app - and specifically in the UI - we have a lot of strings and constants (URL, name of app, button labels etc...). What's a recommended way of managing those strings and constants, considering the following requirements:
We have a lot of on premise installations and we want to be able to easily change things like system name / link url / button names.
We want to easily be able to go over the language in the UI and modify it.
We want to be able to localize the app in multiple languages.
The obvious method is to have the strings scattered all over and utilize find-and-replace, but we are wondering if there is a better way to centralize string management.
You could route your scripts though a configuration file so that you have all of these in one place to modify them. This is common in most CMS systems, i.e. Wordpress, Opencart.
Google the term i18n and you should be able to find a heap of information on internationalisation.
Here is a simple class that I saw which might make it easier to understand how this might work out for you in your project.
I am new to spring mvc. I have a lot of doubts to be cleared before i can continue.
I want to create a simple application wherein an employee details such as name age phone etc is entered and through ajax call the form data has to be to sent to server using json. For server side i am using spring. And the submitted data has to be shown in a jquery data table. And again to retrieve data an ajax call has to be used to get the data as a json. And no binding tool like jackson should be used.
1.) how do i go about creating an application in eclipse. If i should do a simpel java project or a dynamic web project?
2.) Could any one pls provide a sample code of each of the steps.
Thank you in advance
First, I think it's easier to start with Maven, create a WAR project, and use that to generate the Eclipse project files, which you can then import. This has the advantage of allowing Maven to not only create the correct folder structure, but also let it manage your dependencies. There are plugins for Eclipse that help you work with Maven, and you should be able to find lots of How-Tos using Google. Otherwise, you would have to create a project type that generates the WAR, one of which I believe is a Web Project, and layout the folder structure manually.
After you have the proper folder layout, you will need to setup your web.xml to enable Spring, add your Java classes and view files (html, jsps, whatever), and build a WAR. The final step would be to deploy that WAR to a web container of some sort, like maybe Tomcat or Jetty. You can ether run it externally, or configure Eclipse to deploy and launch your WAR in the IDE directly. I prefer the latter approach, as it makes it easier to setup debugging, not that running it external makes it impossible.
In addition, I would recommend adding the Spring pluggins to Eclipse, or just download their STS (Spring Tool Suite), which is just Eclipse with all the Spring plugins already added and configured. STS has the bonus of already having tcServer available, which is Spring Source's flavor of Tomcat. Again, loads of how-tos available on how to do all of this.
Edit to answer first comment
I don't know if I can address your comment here fully, as it's a very broad request. You are basically asking how do I write a full application using jQuery and Spring MVC. The volumes of books dedicated to this subject, as well as many websites you could visit that give tutorials on how to start developing. In fact, I think the Spring website has a tutorial for building their demo Pet Clinic site using Spring MVC. What I will try to do is give you some direction on what you should be asking.
Spring MVC, as the name suggests, is a Model-View-Controller framework that leverages the Spring Framework. I will not attempt to go into any great detail, as again there are volumes of books out there on the subject of Spring and all its wonders, but in general Spring MVC wants an application broken into the following chunks:
1. The Model
These are the objects you are using to represent your "data". This can be data from a Database, flat file, some other web service call, or maybe just passed around in your Controller. You will hear them commonly referred to as domain objects or entities to name a few. But, no matter how you refer to them they are typically POJO (Plain Old Java Objects) Java Beans with no real business logic, who's only existence is to represent some "data" and how it relates to other "data".
Some people prefer to have this object know how to read/write itself to its data store, some people like to have an external object that is only used to handle the read/writes. These are sometime referred to as a DAO (Data Access Object) or a Repository. There are also frameworks you can use for dealing with this stuff, like Hibernate or JPA for databases.
2. The Service Layer
This isn't represented in the MVC acronym, and one might argue this is part of the "Controller", but it's usually a good idea to put your business logic into a service layer. This is typically a POJO class that has methods to do the things you need to do with your Model objects. It houses your business logic so all the business rules are in one place. These are usually split to represent business functions. For instance, if you had an application dealing with car purchases you might have one service class to deal with the User related functions (create a user, update a password, get his preferences), one to deal with inventory (what is in stock, what is on its way, what is the current sales price), and one to deal with making a purchase (validate the customer's credit, start the tag process, etc). Its also common for these services to have reference to each other. For instance, the User service above might use the Inventory service to get a list of VIN numbers for cars Bill sold last week.
3. The Controller
The controller is what glues the "view" to the service layer. It provides the mapping of the URLs in your app to the function(s) they perform in the service layer. Most people try not to clutter the Controller object with too much code, and try to push as much down into the Service layer as they can. But, as long as it's simple logic I personally don't mind having a tad bit of code in the Controller.
4. The View
This is what you are sending to the user. It may be a web page backed by a JSP. It may be an Excel spreadsheet report generated from user input. It may be a simple JSON response to a REST call. It's sort of "the sky's the limit" here. But, for the most part this is either a JSP view or a JSON or XML response from a web service call.
Now to address your comment more directly...
Since you are a novice, I would recommend one of 3 approaches:
Go get a book...do what the book says to do. There are tons out there. Find one that has a good walk-through of a project, and copy/paste their procedures. A good book will usually have a chapter on how to setup all the necessary tools (Eclipse, Tomcat/Jetty, etc)
Find a good how-to on the Internet. There are lots of people that have tutorials. Find one and copy/paste their procedures.
Use something like Spring Roo. Spring Roo is a code generation tool that can be used to build a fully working site with little to no code. I am a big fan of Roo, especially for lone developers not working in a team, as it can generate a TON of the boiler plate code most developers hate to write. It also does things in a very Spring-like fashion, since after all it was created by the Spring folks.
These will get you past the "how do I create the project in Eclipse" problem. Part 2 of question one is a little more tricky. I would say, for now, don't focus on AJAX and stuff. Focus on simply understanding how Spring MVC works. The problem is, you are basically trying to cram 10 things down at once. Spring MVC is hard enough to get your head wrapped around (the annotations, JSTL, EL, and the Spring custom tag libraries, not to mention all the other things you will probably be touching like Spring Data, etc), but then you want to add dynamic web pages, which is JavaScript (and most likely some framework like jQuery), and to cap it off you don't want to use anything like Jackson (not sure why, but ok...) to help ease the transition from Java to JavaScript. That's a tall order. Again, I would cut out AJAX/JavaScript stuff at first, get a good handle on how a SIMPLE application is built, and then you can jump into all the dynamic stuff.
For the last question, providing code samples, I would point you to mkyong's fantastic blog full of Spring-related tutorials as well as Spring's own Tutorial site and Spring's Sample site as a good starting point.