I am new to a project where developers still share code by sending files by mail.
We are using eclipse and cvs.
Developers from offsite send there code for reveiw to onsite where other developers take files one by one from there mail and replace in eclipse. It is ok for 2 or 3 files. But as the files keep on increasing this task really becomes a pain.
We cannot put the source files into the cvs as untested code from offsite can crash our build server.
Here my question begins:-
What can be the better ways to share code?
We dont want to create branches for each change because in this case we will end up with 10-12 branches everyday.
Code should be tested via continuous integration, especially in your situation where your programmers are scattered literally across the world. Your offshore people should be using unit/integration testing to insure that they don't break the build. You should institute process where before they finish for the day, they verify the integrity of the build.
If they are not, they are not worth the money you are paying them.
I suggest you give the offsite developers the ability to perform the same test as your build server. There is no reason they should be sending you code which they cannot test (or test that it at least runs without crashing).
Is there any reason they cannot access your systems via VPN. That way they can test the code via your's or a second build server and merge the code themselves.
Related
Im thinking about creating spring boot application that i would like to comercialize some day.
I planned to build a Jar that i would allow to download, and once client launched it locally and provided some license key, it becomes useable.
I have some doubts about this distribution strategy especially in the meaning of the safety of the code and licensing.
If i provided a Jar, anybody may try reverse engeenering on it - so its easy to be hacked or cracked.
Turning it into executable is more user friendly, also possibly may hide the code better, but still i think its relatively easy to be reverse engineered.
It made me think about obfuscation. If i completely messed up the app before prod build, it would be a way harder to understand or change the code. It may seem okay in the matter of "copying and modifying" the app, but still i think it would be easy to locate licensing limitations in the source files. For example: limit for 5 users can be easilly located in sources by value "5" or the message the user sees, and even if code looks awfull, this lines can be removed, project compiled again, breaking the limitation and wasting my entire effort.
It will be small application, I want to provide clients the instalator, and let them set it up personally. I dont want to be responsible for settting it up in the cloud for the client (without publishing instalator or Jar), as clients may not be interested in cloud based access.
Could You advise me some wise solution for this situaltion?
Thanks in Advance ! :)
The short answer is that there is no way to prevent reverse engineering if someone can run the software on hardware that they control.
The only way to 100% prevent reverse engineering is to ONLY run the software on a platform that you control ... and that can prevent them from getting a copy of the executables.
There are a couple of ways that can make reverse engineering harder:
Use an obfuscator on your JAR files. It will make it harder for someone to read the decompiled code. There are 3rd-party obfuscator products you could use.
Use jpackage (or a 3rd-party tool) to create a native executable for your application.
But beware that modifying an application to disable a license check is much simpler than full reverse engineering. A determined software engineer (or hacker) will be able to do that, given enough time and incentive.
Look at this problem another way:
There are many people and companies making money out of writing and supporting software without resorting to license keys, obfuscation and so on.
Conversely, there are probably millions of aspiring software entrepreneurs who never even turn their clever idea into a worthwhile (saleable) product.
Conversely, there are millions of apps (e.g. in Android app stores) that are simply not worth the effort protecting from IP theft.
Don't get lost in the problem protecting your IP before you have actually created it. And don't overrate its (hypothetical) value.
I wanted to know what is the easiest way to deploy a web server made using java or kotlin. With nodejs, I just keep all the server code on remote machine and edit it using the sshfs plugin for vscode. For jvm based servers, this doesn't appear as easy since intellij doesn't provide remote editing support. Is there a method for jvm based servers which allows quick iterative development cycle?
Do you have to keep your server code on remote machine? How about developing and testing it locally, and only when you want to test it on the actual deployment site, then deploy it?
I once tried to use SSH-FS with IntelliJ, and because of the way IntelliJ builds its cache, the performance was terrible. The caching was in progress, but after 15 minutes I gave up. And IntelliJ without its caching and smart hints would be close to a regular editor.
In my professional environment, I also use Unison from time to time: https://www.cis.upenn.edu/~bcpierce/unison/. I have it configured in a way to copy only code, not the generated sources. Most of the times it works pretty well, but it tends to have its quirks which can make you waste half a day on debugging it.
To sum up, I see such options:
Developing and testing locally, and avoiding frequent deployments to the remote machine.
VSCode with sshfs plugin, because why not, if it's enough for you for nodejs?
A synchronization tool like Unison.
Related answers regarding SSHFS from IntelliJ Support (several years old, but, I believe, still hold true):
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206592225-Indexing-on-a-project-hosted-via-SSHFS-makes-pycharm-unusable-disable-indexing-
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206599275-Working-directly-on-remote-project-via-ssh-
A professional deployment won't keep source code on the remote server, for several reasons:
It's less secure. If you can change your running application by editing source code and recompiling (or even if edits are deployed automatically), it's that much easier for an attacker to do the same.
It's less stable. What happens to users who try to access your application while you are editing source files or recompiling? At best, they get an error page; at worst, they could get a garbage response, or even a leak of customer data.
It's less testable. If you edit your source code and deploy immediately, how do you test to ensure that your application works? Throwing untested buggy code directly at your users is highly unprofessional.
It's less scalable. If you can keep your source code on the server, then by definition you only have one server. (Or, slightly better, a small number of servers that share a common filesystem.) But that's not very scalable: you're clearly hosted in only one geographic location and thus vulnerable to all kinds of single points of failure. A professional web-scale deployment will need to be geographically distributed and redundant at every level of the application.
If you want a "quick iterative development cycle" then the best way to do that is with a local development environment, which may involve a local VM (managed with something like Vagrant) or a local container (managed with something like Docker). VMs and containers both provide mechanisms to map a local directory containing your source code into the running application server.
I'm looking for a way to test the different functionality of my JavaEE server application. I first tried to do it with Junit and TestNG, but building the different scenario was too tedious.
What i'm searching is a tools that will simulate an user using my server application trough his browser, and then once this scenario is established i could check the output and verify if it's working.
Here an exemple:
An user connects to the server, the server application interface is displayed.
He executes the functionality to modify his personal datas
He modifies the different that he want to change.
He saves the modifications.
Then what i want to check is the actual state of the data in the database.
What i need is something that will simulate the action he did with his browser like i said above...
I've read different article about different tools that could do the works but i'm not sure because i don't really know what to type in google.
I discovered Jmeter (that is not working with my application because of web socket) and the Grinder.
The Grinder seems to be interesting but most of the things i've read about refers to it as load testing tools, which is not what i'm looking for.
Can someone experienced tells me if i can do what i want with the Grinder ?
You can use scripting tools like: Sikuli(Record Playback & Scripting) or Automa (Component Identification Scripting)
The most popular tool currently is Selenium. It will certainly do the job. I would also mention Geb because it provides more convenient API when compared to Web Driver.
I'll also let myself to give an advice, although it doesn't relate directly to your question.
If your project is big enough (4-5 teams over a couple of years can deliver a lot of code), you should think what to automate.
These tests can be very heavy both in terms of CPU load and in terms of time.
So if you'll rely ultimately on these tests, your build will run ages and will be potentially unstable.
So these tools should be used only to complement unit/component and integration testing that should exist anyway and they will use completely different tools.
Also in UI, consider using various testing techniques that would test only the UI side (mock the server endpoints and so on).
I'm looking for a way to boost my team's productivity, and one way to do that would be to shorten the time it takes to compile & unit test & package & deploy our Java EE application which is getting bigger and bigger.
The trivial solution that I know of is to set up a powerful computer with N processors (N ~= num of developers) and a blazingly fast disk system and a lot of memory, and run everything on this computer and connect to it via X remotely. It would certainly be much faster than compiling on our laptops, but still cheaper and easier to maintain than to buy each developer his/her own supercomputer.
Is there another way to solve this problem? For example, could we run our IDEs locally and then tell it to remote compile java source? Can Netbeans / Eclipse / IntelliJ / etc. do this? Or is there a special tool that enables remote java compilation, also that makes use of multiple processors? It need not be free/open source.
Unfortunately our laptops MUST run a (company managed) Windows Vista, so another reason to go for the separate server computer is to let us use linux on it and finally get rid of the annoying managed environment.
EDIT: to sum up the answers so far, one way to shorten build times is to leave compilation for the developers individually (because compiling is supposed to be fast), skip running unit tests and hot-deploy (without packaging) to the container.
Then, when the developer decides to check his/her code in, a continuous integration server (such as Hudson) is triggered to clean & build & run tests & package & deploy.
SOLUTION: I've accepted Thorbjørn's answer since I think that's going to be the closest to which way I'm planning to proceed. Although out of curiosity I'm still interested in solving the original problem (=remote Java compiling)...
You essentially need two workflows.
The OFFICIAL build, which checks out the sources, builds the whole thing from scratch, runs all the unit tests, and then builds the bits which will eventually ship to the customer after testing.
Developer hot-deploying after each source code change into the container the IDE knows about.
These two can actually be vastly different!
For the official build, get Jenkins up and running and tell it to watch your source repository and build whenever there is a change (and tell those who break the build). If you can get the big computer for building, use it for this purpose.
For the developers, look into a suitable container with very good IDE deployment options, and set that up for usage for each and every developer. This will VERY rapidly pay off! JBoss was previously very good for exactly this purpose.
And, no, I don't know of an efficient remote java compilation options, and I don't think this is what you should pursue for the developers.
See what Joel thinks about Build Servers: http://www.joelonsoftware.com/articles/fog0000000023.html
If you don't like Jenkins, plenty others exist.
(2016 edit: Hudson changed to Jenkins. See https://stackoverflow.com/a/4974032/53897 for the history behind the name change)
It's common to set up a build server , e.g. running hudson to do the compiling/packaging/unit-testing/deploying.
Though you'd likely still need the clients to at least perform a compile. Shifting to using a build server, you might need to change the work process too if you arn't using a build server now - e.g. if the goal is to take load off the client machines, your developers will check code in , automatic unit tests gets run, instead of running unit tests first, then checking in.
You could mount each developer dir with ntfs on the powerful machine and then create External Tool Configuration in Eclipse (GUI access), that would be triggering build on external server.
JavaRebel can increase productivity also. It eliminates the need for redeployments..
You can recompile a single file and see the changes being applied directly on the server.
When things start getting too big for efficient builds, it may be time to investigate breaking up your code into modules/JARs (how it breaks apart would depend on many project specifics and how your team tends to work). If you find a good setup, you can get away with less compiling (dont always need to rebuild the whole project) and more/quicker copying/jaring to get to the point where you can test new code.
What your project need is a build system to do the building, testing and packaging for you. Hudson is a good example of such a continuous integration build system.
I've been beginning a client-server application. At first I naturally created two projects in Eclipse, two source control repositories, etc. But I'm quickly seeing that there is a bit of shared code between the two that would probably benefit from sharing (in the same project or in a shared library) instead of copying.
In addition, I've been learning and trying test-driven development, and it seems to me that it would be easier to test based on real client components rather than having to set up a huge amount of code just to mock something, when the code is probably mostly in the client. In this case it seems having the client and server together, in one project, thinly separated by root packages (org.myapp.client.* and org.myapp.server., maybe org.myapp.shared. too).
My biggest concern in merging the client and server, however, is of security; how do I ensure that the server pieces of the code do not reach an user's computer? When Eclipse bundles a JAR, I'd have to pick out the server-specific bits and hope I don't miss any, right?
So especially if you are writing client-server applications yourself (and especially in Java, though this can turn into a language-agnostic question if you'd like to share your experience with this in other languages), what sort of separation do you keep between your client and server code? Are they just in different packages/namespaces or completely different binaries using shared libraries, or something else entirely? How do you test the code together and yet ship separately?
A lot of this is going to depend on your specific implementation but I typically find that you have at least three assemblies (binaries) that are created with a project like this.
A Common DLL that contains shared functionality that is used by both the client and the server
The DLL/Exe for the client
The Dll/exe for the server
Using this approach you have your shared items, but you make sure that items that are server specific are never in a distribution that is sent to the client workstations.
Neither. It should be 3. (common, client and server) However, it doesn't necessarily need to be three "projects". Using Maven I create three sub-modules under a master project. You can do something similar using Ant.
I have found that at least one project per finished entity (server deployment, client binary, etc) works well with e.g. Hudson. Then you can have shared code in a basic project available to all.