I'm customizing some Airflow pages/views as well as adding some of my own. Running in a Docker container, it takes several minutes from the time I apply my changes to either my templates or to Airflow views.py to when refreshing the web ui will reflect the updates. Or I simply have to restart the webserver.
I've tried setting FLASK_ENV=development as well as setting flask_app.debug=True in app.py but I'm still seeing a relatively long lag for changes to take affect. Trying to see if anyone knows of a faster way to trigger the updates, to help speed up my development and debugging. Thanks.
Related
I am new to Meteor. I just start using Meteor for the first time. It seems a bit slow. I am developing on a Macbook Pro with SSD. I am using Firefox, and Vim. I tend to save the files frequently, causing it to refresh the browser. It takes a few seconds for the browser to refresh. I do not have much code yet. Are you experiencing this slowness? How can this be improved? Does MDG have any plan to improve this? If I make change to a file, can we cause the browser to just reload that file rather than doing a full build and causing the browser to reload all the files? Am I missing something? Thank you!
Unfortunately, you can't do anything about it. However, the complete rebuild takes place only when you change the server side code. For any client changes, the change is almost instantaneous.
You can try some workarounds by removing some packages from meteor but they will affect debugging.
There is a great thread on this issue on Meteor's Github Issue section. You can find it here
Also, you may consider using WebStorm as it is the only IDE with built-in meteor support. May help you speed up your dev time.
UPDATE: You may try using import functionality in Meteor 1.4 to define file dependencies. Also, have a look at this package
I installed Meteor (p.s I'm new to app developement) onto my laptop (running Windows 10) and have created an app for which I have downloaded packages for (materialize, accounts-ui and passwords). The problem that I'm facing is that whenever I make changes to the html,css or js files, I get "client-modified" on my terminal, but it never actually refreshes. It's just stuck there in a loop after no matter how many modifications I make. Is this due to the current Meteor version I have installed (1.2.1)?
=> Client modified -- refreshing
This happened to me also, yesterday and today, that's how I found this question.
My observations are:
check if the app is running and working despite the apparent hang. If it does, try making a simple change in a html or template file and see if the app auto-updates. It did for me, but your mileage may vary.
If it gets too annoying, you can always just kill and restart the app. Shouldn't take too long. Check if this improves the situation.
If 2. does not help you may try "meteor reset" to clean things up, but ONLY if you just started developing your app and don't care about losing any app data (MongoDB get's wiped along with the rest of the /.meteor/local folder)
Hope the above helps...
Norbert
My Meteor file change watcher is taking forever to detect my file changes and refresh the browser, sometimes even longer than a minute. This makes developing a real pain.
My Meteor is running inside an Ubuntu-VM. The projects folder lies in my OSX and is mounted inside the VM. So I'm aware that inotify/kqueue won't work, so Meteor should fallback to stat polling.
I even set the environment variables according to this post, but the behavior is still the same.
METEOR_WATCH_FORCE_POLLING=true
METEOR_WATCH_POLLING_INTERVAL_MS=500
Is there any way to fix this annoying behavior?
The folder from OSX is mounted as a nfs share btw.
Update:
I did some testing and there is no difference if the application has a big amount of packages or is taking long to build, even with the very basic app you get after meteor create I still get the same behavior.
If I change a file in the VM (so that inotify works) the refresh is happening instantly.
I've have apps in production that incrementally become slower when adding packages, both 3rd party and private packages. I also discovered that adding 3rd libs directly on the client/lib increases the reloading time.
I'm not sure if Meteor 1.0.2 actually solved the problem of watching the directory efficiently.
What version of Meteor are you using?
Much of this lag-reloading issue was addressed on Meteor 1.0.2. While it still takes some time, I would say was ~5x faster on my experience.
I've recently started working on Grunt and figured out how to use its built-in live reload feature. I am using a WordPress theme to develop and asked the developers if they could better include the Grunt live reload functionality into the theme. They would insist on using the application instead (which isn't grunt). They said it would be dangerous to use as you should remember to remove the file from the production environment when you're done, even though I recommended a simple way to make sure it only stays in the development environment (which went ignored). I'm just curious as to what's the big disadvantage in using the grunt live reload vs the application? To me it seems better to keep it all with Grunt (by adding a couple of extra lines of code) instead of adding another tool to my workflow, granted it may be more dedicated to live reloading.
I work with grunt-contrib-watch with the livereload in almost every project and I didn't see any disantages so far.
The only problem that I can point out, is that livereload should be used only for lighter tasks or it can be a bit annoying if you're making him track heavy tasks.
It seems to me that your coworkers are being a skeptical for no reason, if you're not using grunt or gulp, putting them on your projects might be a huge improvement.
Each time I run a test using TestDriven, it creates another "rocket" icon on my system tray. I have to manually do right-click Quit to get rid of them. How can I avoid this?
Check for any open file handles you may be creating in your tests. Depending on the size of your test suite that may be too time consuming and tedious. There's an option to turn off caching the test process between test runs in the options for TestDriven.Net. This seems to be designed for instances like what you're seeing. From their documentation:
Cache test process between test runs
By default the external test process will be cached when the ‘Run Test(s)’ command is used. This process appears in the tool tray as a rocket icon which can be used to kill the process. This is fine unless one of your tests starts leaking leaking native resources (such as leaving open a file handle). The best solution is to fix the resource leak, but you now have to option to work around the issue by killing the test process at the end of each test run. This can be useful if the resource leak is in a 3rd party DLL which can’t be easily be changed.
From here: http://weblogs.asp.net/nunitaddin/archive/2008/12/03/testdriven-net-options-pane.aspx
I realize you asked this a year ago, so you may have already figured out a way to fix the problem. In that case, I would ask that you let us know what you did.