Web Developers!
How do you go about organizing your Github projects for your front-end and back-end?
For example, I have a python script that generates a JSON file that the front end JavaScript consumes to generate data on the pages.
Would you create one repository with two directories labeled front-end and back-end?
Or would you make two different repositories?
I'm interested in what developers do in the wild. Because up until now I found myself having a complete clone of my website in a directory on my desktop PC, and just pushing individual files via SFTP from there.
I'm getting to the point where I have enough *.old files that I want to implement version control so I can view much older states of code with Metadata like date and user that edited it.
The answer is yes. Make two different github projects.
Just Like Michael W has stated, "[...] this is highly opinionated". What I find to be the most common approach is to implement a single github project when still in development and especially when you're developing on your own. This is useful because you don't have to switch up between repositories and/or branches, which saves time.
Another common approach is to split them up. However this approach is only possible when both projects can run independent from one and other. In your case it's important to split the project logically. If the python project only generates JSON files and places them on a server location, then I would place that into it's own github project, because the main purpose is to generate files, so the python application can run on a server seperate from the frontend. If the webapp only consumes the JSON files through maybe a rest call or through a connection to a FTP, then also that can be placed within it's own project.
Related
Once an html page has been put together it starts to acquire dependencies on Angular and typescript.
This is not ideal for the web designer who really just wants to be able to view and modify their design. Usually this involves data elements too.
In our team the designer needs to be able to continue to work with html and stylesheets; they are not a separate contracted resource.
Is there a way to set up a project so that the web designer does not need to concern themselves with npm packages, Angular versions and data sources?
I have since had an idea...
As it happens I am a Linux user, the designer is a Mac user. I am wondering if it would be possible to create a project consisting of symlinks to html with typescript stubs.
A mock datasource might also be a viable solution.
I work for a company that develops many websites to be used internally but many have parts that are public facing. It is important that all our sites look the same. In moving to dotnet core we found that we are no longer able to use a virtual directory to host the Layout page for our site.
We were storing our Layout page on a file share and referencing it in our projects with a virtual directory. This way if we needed to change the information in the footer, header, or some style/js we could upload a single change to the Layout page and that change would take place on all our sites.
I've tried researching any possible ways and the only thing I can come up with is a custom middleware that downloads the layout page from the file share and updates the current layout page if it is out of date.
.NET Core gives you the capability of creating Razor libraries. This would be a separate project where you can have shared views and reference it to the rest of your projects. You can find a simple implementation here.
You can choose one of these two options to do this.
Reference this project in each solution. Since your solutions directly reference the razor library, any change that is made in the common library will be reflected in every solution without the need of repacking and publish.
use dotnet pack to create a nuget in a shared location. While this option will require you to repack and publish each time, in some cases it would be a more organized solution. You can have a version setup. This means that when you update the shared razor project you will define a new version number. You can update this on each one of your solutions. This reduces the risk of a project breaking. Let's say you have 5 projects and 2 of them are not compatible with the latest update. In this case, you can update the 3 right away. The remaining 2 can be updated when you can spend time updating these projects to match the new requirements.
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
At the moment I'm learning spring and have the basic website running now on tomcat. Can I ask, how do you load images onto the website now and where do you store the images, css, javascript etc in your project folder?
The answer depends a lot on your development/deployment environment. If you are using Maven for example, which has a specific directory layout, you would put the files in src/main/webapp/.
If you are using Eclipse as your IDE and use Ant to build your project, you would normally use WebContent/.
In any case, I would advise to use specific folders for each type of file. You can still use Tomcat Filters, if you want to influence the headers that are sent with the files. (Important for caching, ...)
(my apologies for the non-specific wording of the question title, and for liberal use of öpen source" when I actually mean "project setup at SourceForge")
We have recently open sourced a 3D modeler we'd been selling for a couple of years, with the main goal of keeping the application alive. We setup shop at SourceForge.net, and are now working towards a process resulting in a steady flow of binary releases. So far, everything is swell.
However, besides the main application, we had also developed a couple of plugins (mainly for different import/export formats). Currently, these are still closed source, but we would like to open those up as well (3rd party plugin developers can take care of their own or donate and open the source). The question really is, should our plugins be hosted as a project on their own or not?
The options I see are:
Add the plugin sources into a subfolder of the SVN sources
Create a separate project for the set of plugins
Create a seperate project for each individual plugin
Which setup is the most practical and/or common, and how should I deal with the binaries?
When the application was still closed and commercial, it was kinda important that the plugin binaries could be updated seperately fom the main application, but now that everything is open and updated frequently, that's not so much of a big deal anymore. Also I'm not sure I want to bother contributing developers with a whole bunch of plugin sources they care nothing about as part of the main project.
Add the plugin sources into a subfolder of the SVN sources
I think that is a good idea if you don't have too many plugins. You could create a folder structure as shown at the end of my answer in order to manage plugins independently. But in this case you won't have fine control over SVN access.
The advantage is that you only have to maintain one project website (if you create one at all).
Create a separate project for the set of plugins
That's what Notepad++ does, for example. Their plugins are hosted on a separate SourceForge project. Having one download page full of plugins and another download page full of binary releases of your software improves readability. But don't forget to mention on the project web page that there's a separate plugin project.
It also has the advantage that you can manage the project web sites independently. For instance, you could put other users in charge of caring about the plugin site (if you find somebody who wants to maintain them).
Create a seperate project for each individual plugin
Not a good idea, maintenance will be harder this way, as you'll have multiple projects, repositories and project websites.
But it has an advantage though: You can be more fine-grained in granting people access to developing the plugins. For example, users A and B are allowed to work on plugin X, but not on plugin Y. With separate SF projects, this is easy to achieve. Same applies to the project web sites, of course.
So, as a conclusion, I would say that the more you care about SVN access rights and the more plugins you have, the more it makes sense to create one or more separate projects for your plugins.
Example SVN structure from #1:
/modeler
/trunk
/branches
/tags
/modeler-plugins
/plugin-x
/trunk
/branches
/tags
/plugin-y
/trunk
/branches
/tags