Using IDE together with docker - docker

I started looking into docker lately and I understand a lot of the benefits it offers I think, you can quickly create a docker container and run it on different machines. Building (compiling) is also relatively easy, you can download the maven image for example and just build your code. That works fine. So, building is easy, testing is easy and deploying (and running) in production is easy.
What I don't understand is how docker can make the development phase easier. And what I mean with the development phase is, starting up your IDE, reading code, quickly navigate through your methods definition using the methods the IDE provides, use intelliSense, etc. Then change something, run a unit test, try a different third party library, etc. All things you can do with your IDE. But I don't understand how to do this with a docker image. I've read a few posts about starting the IDE from within your docker container, but that requires setting things up with a windows manager and I am not sure if that's the way to go.
Of course I can set up my laptop in such a way that I can do all of this with my IDE, but that way I bypass all of the benefits docker should offer. I still have to download dependencies, set up environment variables, do a lot of manual settings etc. And not just me, but everyone in the team.
So, not a very concrete question, possibly a duplicate, but I just can't wrap my head around it, how to use an IDE together with docker?

Yeah it's hard. It also depends on what language/framework you're using. But the things you mention are all easy to accomplish. For example we use Ruby a lot and someone in my team uses RubyMine to work with his code. That source code is mapped onto the container so the changes are reflected immediately. If you want to run a test, I'm sure you can override the command your IDE brings by default with something custom like docker run --rm myapp ./run_tests.sh or similar. At least that's what I do with VIM.
Probably the most important missing part when doing dev with Docker is debugging. I think JetBrains is starting to add features to their IDE's but I'm not sure on the status of that.
Also, almost every IDE or good editor has an integrated console. You could maintain a docker exec sessions opened there and run all your app commands, like tests, generators or any other. Even do some basic debugging.
Hope it helps.

Related

will using Docker allow me to not install necessary requisites?

I am a bit confused about Docker and how can I use it. My situation is the following:
I have a project that requires the use of a requisite, in my case installing ROS2. I have installed it in my system and develop a program. No problem there.
I wish to upload it to Gitlab and use CICD there. So I am guessing I will push it to my repository and then build a pipeline where I can use as image the docker image for ROS 2. I haven't tried it yet (will do it tomorrow) but I guess that is how I should do it.
My question is, can I do something similar (or how to ) in my local machine? In other words, just use the docker image and then develop and build over there and not install the requisite in the first place?
I heartily agree that using docker to develop locally improves the development experience, primarily by obviating system specific dependency management, just as you say.
Exactly how this is done depends on how many components you need to develop simultaneously, and how you want the development environment to behave .
An obvious place to start might be docker compose, a framework for starting multiple docker containers. https://docs.docker.com/compose/gettingstarted/ looks like quite a nice tutorial on the subject, and straight from the horse's mouth too.
However, your robotics project (?) may not be a very good fit for the server/client model behind the write - restart python - execute client - debug - repeat cycle in the document. To provide a better answer, we'd need a lot more understanding of how exactly your local development works - what exactly you want your development process to look like in this project might require a different solution. So add some workflow details to your question!

What is a good Sublime Text workflow for sharing a common setup between several platforms

I'm using Windows, Mac and Linux machines in my daily duties. On all machines, I program in C++ and various shells scripts. So far I've adopted the various "main" IDEs on each platform, but the diversity is irritating. I'm therefore looking into the possibility of using Sublilme Text on all platforms.
I have a setup of Sublime Text on Windows that works perfectly and would like to use the same on the other platforms also, so that when I change something in my Sublime setup on, say, my Mac, I can easily pick up the latest setup on my Windows machine the next time I'm there.
Is this possible on the 3 mentioned platforms, without getting (more) grey hair? If so, any suggestions or experiences thereof?
Many folks upload the "Packages/User" folder to GitHub (or your VCS service of choice). Then, they use Package Control to install their packages. Package control, through a settings file, will install any missing packages on a particular machine. I wrote a bit more about it here. You would then clone the git repo onto each machine, pulling updates when you decide to change something.
Alternatively, you could probably use a cloud service + symlinks to keep things auto synced, but I've personally never used it that way.
There are some plugins that are platform specific, so keep an eye out for those.
There's also the Package Package Syncing, which syncs installed packages and settings via some cloud service.
Works quite nicely, and automatically.
Has the advantage that you don't have to push/pull some dotfiles repo all the time.
No idea though whether this will work seamlessly across platforms (meaning whether all the settings will be platform-independent).

How do I leverage package maintainers' experience with Docker?

When building Docker images, I find myself in a strange place -- I feel like I'm doing something that somebody has already done many times before -- and did a vastly better job at it. In most cases, this gut feeling is absolutely right -- I'm taking a piece of software and re-describe everything that's already described in the OS's packaging system in a Dockerfile.
More often than not, I even find myself installing software into the image using a packager manager and then looking inside that package to get some clues about writable paths, configuration files, open ports etc. for my Dockerfile. The duplication of effort between OS packager and Docker packager is most evident in such a case which I assume is one of the more common.
So basically, every Docker user building an image on top of pre-packaged software is re-packaging almost from scratch, but without the time and often the domain knowledge the OS packagers had for trial, error and polish. If we consider the low reusability of community-maintained images (re-basing from Debian to RHEL hurts), we're stuck with copying or re-implementing functionality that already exists and works on OS level, wasting a lot of time and putting a maintenance burden on the poor souls who'd inherit whatever we might leave behind.
Is there any way to resolve this duplication of effort and re-use whatever package maintainers have already learned about a piece of software in Docker?
The main source for Docker image reuse is hub.docker.com
Search first there if your system is already described in one of those images.
You can see their Dockerfile, and start your own from one of those images instead of starting from a basic ubuntu or wheezy one.

Do you have a Rails development environment running under Windows you're happy with?

My current Rails development environment is Aptana + RadRails plugin on Windows XP and it's a little slow running tests, rake, and generators.
If you've evolved and proven your Windows Ruby on Rails development environment into something you're happy with and is fast, please share the details below.
Many thanks,
Eliot
http://www.akitaonrails.com/2009/1/13/the-best-environment-for-rails-on-windows
try this guide
To add on to Omar: instead of dealing with VMWare, you could install Portable Ubuntu, which runs inside Windows. Though you will get a performance hit from doing so, it will give you a Linux environment to work in and you won't have to worry about installing another operating system.
Although I work primarily with Ubuntu now, I was using a windows machine with Vim on it. Vim has a plugin called rails.vim. It understands the rails structure very well. These the things I found very useful.
Navigation between model, controller, unit test, functional test within 3-4 keystrokes using :RModel, RUnittest, :RFunctionaltest, RController.
Ability to run a unit/functional/integration test right away using :Rake
A quick jump to console using :RConsole
A quick jump to helpers using :RHelper
the goto file 'gf' shortcut now behaves in a predictable manner. It even looks up files inside gems you have installed.
The video on the site hardly does any justice to it. If you are not a vim user, then I would suggest E text editor. It is not free but worth every penny you pay.
I am led to believe that Rails (well, Ruby, really) on Windows is generally slow, compared to *n[iu]x, but since I haven't experienced the latter, I remain blissfully ignorant. In particular, there's a lag while the Rails environment loads that is tedious even on a fairly fast (3GHz Xeon) box.
On top of that, there's the overhead that an IDE brings. Of the more recent, I've tried NetBeans and RubyMine. Both are very capable and a little slow, compared to my normal working environment of command line and test editor, which pretty much suffice 95% of the time: I find I don't need much IDE support when I'm developing test-first. I still find myself mostly using SciTE, largely because of the "Run" command being easily accessible. With a little tweak to the "require test_helper" line in my tests, a single test execution is no more than a F5 away, and the whole suite available from the command line with a quick "rake".
If I need to debug into the framework to clear up (usually) some misunderstanding on my part, then I currently lean towards NetBeans, where the debugger seems a little more intuitive. I suspect RubyMine may have more power, but I haven't found myself needing it yet.
Irrespective of all the above though, the key to performance on Windows is the time to execute `environment.rb' and that's not an easy nut to crack. (Here's hoping I'm totally wrong and I've missed something super-cool, btw.)
I would seriously consider against Rails development inside Windows and my reasoning behind it is because you won't be using a Windows machine in production.
You will most likely be running some sort of Linux machine because Passenger wont work on Windows, mongrel_cluster (last time I checked) also doesn't run on Windows and IIS is a nightmare. Trust me, consistency between development and production is a huge bonus.
If you must run Windows, then I would recommend running Rails inside a Virtual Machine with a Linux distribution of your choice. That way you could use something like e-texteditor (which comes highly recommended as a great alternative to Textmate) and have a Samba share to a git/svn repository on your Virtual Machine.
Check VMWare Server out and install CentOS / Ubuntu. It's free and will give you an insight into development in Linux which is ultimately where you want to be at.
I'd recommend jruby for windows.
Ruby in Steel isn't bad if you want to use Visual Studio.
It's got it's issues, but it's not as "slow" as the eclipse variants I've tried.
RadRails so far has the most complete code completion I've seen, as it knows about your models and such far more than Ruby in Steel. Even if it's slow to load the data for it, at least it's there.
If there are not immutable reasons that you are using Windows XP, you should just switch to Linux. There are none of the weird compatibility issues that arise on Windows. If your application will eventually be deployed to a linux machine, it's easier to develop on. Plus, it would solve your performance issues.
https://help.ubuntu.com/community/RubyOnRails
If there are constrains that make Windows absolutely necessary, please revise and specify.

What are good code deployment strategies?

I am working on a Django project. And our team follows agile practices(TDD,very short launch times etc..)
When it comes to deployment stage of a feature, we follow manual procedures to get the code deployed on to our production machine. Manual procedures in the sense, run the test cases (of the entire project) manually and run the syncdb (or any latest db changes) manually and other stuff.
This manual stuff is taking about 1/2 hour per day,everyday. So I wanted to automate this. So is there any automatic deployement system or something that takes the commands I give and do what I want or it should be done only MANUALLY?? (using a simple shell file which has got all my commands. In which case, I need to learn shell programming a bit because I don't want to update my latest code in my production machine if any test case fails. So such a sort of conditions exist for deploying, which may involve a bit of shell programming. I guess!)
I just started researching this myself and it looks like the Python-equivalent of Capistrano is Fabric, although maybe not as mature. There seem to be a growing number of people wanting to switch over simply because Capistrano is too ruby/rails centric, although I haven't seen anyone complain about Capistrano being incapable or lacking. YMMV. More info here and here.
EDIT: Looks like Fabric is undergoing a lot of changes. They're moving their homepage to http://docs.fabfile.org/
So in Agile terms, you've identified duplication in your deployment process, now you're looking for ways to refactor it. ;-)
In the Ruby/Rails world, you'd turn first to Capistrano or Vlad The Deployer, and in the Python/Django world you'd turn to the equivalent, except AFAIK there isn't one.
It seems from this post that Capistrano has been used successfully to handle Django deployment, so that's an option worth exploring.
Beyond that, why would you need shell programming? You have a super-powerful scripting language in Python - why not automate your manual process in that?

Resources