Couple of questions for folks:
Within our Meteor app we have a scheduled job / background process that runs which is pretty separate and removed from the core web experience. We'd like to run this job on a separate dyno. Anyone have experience cutting up the meteor app and having it run different places? Is this even doable?
I believe this will involve doing some stuff in the Procfile - but am struggling to figure out what to do!
Also wondering about the "buildpack" - given the need for "sticky sessions" which one is the best to go with? Horse? Other?
I hope we are on target enough that these questions even make sense!!!!
Tewks
same ask on Meteor forums - I'll cross reference any helpful comments
(https://forums.meteor.com/t/deploying-meteor-on-heroku/15675)
Related
I am interested to know if someone has explored using Jenkins only as a backend tool but use some better web based UI to start build, and report job details.
Jenkins is really amazing at what it does and with pipeline, it actually does lot of things that a modern build system might need. However, I am really not happy with the UI it gives users, it is just very dull and is not very intuitive. I was hoping if someone had explored developing their own UI to show the different jobs configured in jenkins, taking inputs from users and running the jobs and showing the logs in a more intuitive way.
For now, I found that Blue Ocean Jenkins Plugin is the best way to get a much improved UI for jenkins.
Lately I've been getting more and more interested in Meteor.js. At the moment I'm developing a new web project of mine. What I can't get out of my mind is the Autopublish feature of Meteor. At the moment of writing my MongoDB has a total of 32453 records, therefore, as you can probably guess I had to turn off autopublish and subscribe/publish manually.
I've read a mouthful of guides now and it seems to be a completely common practice to turn off autopublish as soon as your application is created. This makes me question - does the feature have any practical use in a real world scenario? I can see it being useful for the shock and awe effect of the examples, but aside from that, it seems more or less pointless. I might be missing something very obvious though.
Autopublish is designed to be turned off before production. It's simply a feature to speed up development in the early stages, and that's all. From the Meteor Docs:
By default, a new Meteor app includes the autopublish and insecure packages, which together mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools, but typically not appropriate for production applications. When you're ready, just remove the packages.
You are not missing anything. It was added to make the examples work and to get users up and running quickly when working on new projects. I can't think of a compelling reason for a production app to have autopublish on.
I have just started working with a new company in a very small IT department, and an even smaller dev team (just 2 developers including me). We mainly develop in house web applications for the company.
Now my background is in desktop applications so this job comes with a slight learning curve for me having never developed ASP.Net web applications before. Currently we do not use TFS however I have made the suggestion and it is something we are going to be adopting soon.
I am also considering recommending we move our SQL databases into database projects as currently we do nightly backups to protect the data but all the updates are manual, we connect to the database and execute queries etc.
Im not a DBA but in my last job we were in the process of migrating our databases to database projects and the DBAs seemed to love the idea. What would the benefits and potential downfalls of this be? Would it aid us with updating databases in our live enviroment after development has been done? Obviously we dont want to loose any data but just update tables / Stored Procs etc.
As a side question I have very limited knowledge of TFS, and although we are going to be using it to handle our version control is it possible to use TFS to update our live websites automatically once development has finished?
Sorry if this is quite a broad question, I am attempting to research this myself but I would like to hear from people who actually use the products and do these things.
Thanks
About database projects: I, and several dba's I know, have had mixed experiences with them. I'm not sure they are exactly where they should be at this time but it may be simply a function of how I work. The deployment model is... difficult and can result in some unexpected behavior. If you go this route test test test to make sure you understand exactly what's happening.
If you are just trying to get version control for the database you might consider SQL Source Control from Red Gate. It looks pretty nice and hooks into TFS. I used one of the early versions (beta and 1.0) for awhile and was very happy with it. Now that I think about it, I'm not sure why I don't have it here... ;)
As far as deploying out of TFS, you can absolutely do this. We have a build server set up so that whenever code is checked in the build server automatically spins up to compile and deploy it out to one of our testing sites. Look here for a primer to get you started. This does require some configuration on your web server to properly support and the documentation is spotty at best.
Once you are happy with the test area, you can hook something into changes to the Build Quality so that it pushes the code to a staging or even production server... Or simply have a build setup to recompile and deploy out there. Although I don't recommend doing production pushes this way. Not because of a technical issue, but rather a timing one. It's usually much faster to just copy / paste from one location to production when necessary thereby limiting downtime.
I was wondering if you guys know of any software that allows me to jot down notes in a project based environment, as well as enabling me to track bugs or other issues in OSX. Basically, I have a lot of little projects on the go, and I would like to have one place where I can store and organize all their information. I have done lots of research on issue tracking systems, but they all seem to be overkill for what I need. I essentially need just a single user desktop application were I can enter bugs for myself to view later. So far I have basically been doing this with sticky notes/other such applications, but I think its time for a step up to an application that stores the history of bug fixes, open issues, etc. Any ideas? Thanks beforehand!
I know you mentioned desktop, but from reading your question I would recommend Trello http://www.trello.com.
Trello is really nice for keeping track of small to medium projects and does not take up all of your time when entering in steps.
I'm a freelance web developer working on multiple projects. Earlier I used to use small applications to keep track of project tasks. Now that the number of projects have increased, I've been using Microsoft Project Professional. The project management software ensures that I can test, report, and track all my project tasks. This helps me be in sync with project progress.
We were searching for a simple bug tracking solution too and found some pretty cool platforms like Instabug, BugSee, ... The problem was that they are pretty expensive, so we developed a new platform that's made for everyone. BugBattle.
https://www.bugbattle.io
It offers something that's called in-app bug tracking, which allows you to report bugs (+ all kinds of useful information like screenshots, meta data about devices, ...) directly within your app. It's super easy & fast to integrate. I takes about 2 minutes or so to integrate it within your websites, apps, webapps. Def. worth trying.
In addition we added features like the BugBattle Challenge, which enables you to basically fight against others in bug fixing challenges. Haha, it should be fun to fix bugs :)
Hi I would like to know how many of you have used Workflow in your production environment and Was it good idea? I mean we can create the same thing using DB and scheduler service
We use WF in our production enviorments. We have 6 different workflows that can be run. These split into 3 statemachine and 3 sequences. I would use it again in some circumstances, but I would not in others. I would claim that the statemachine part of the workflow was tacked on the end quickly, I'm not sure it a core part of the workflow all the way through design.
I would use workflow again for short running processes like quotes or transforming things before sending them to supliers that kind of thing.
I would not want to do it again for a long running statemachine - mainly because there is not a built in WF upgrade process so we ended up writing our own. There are also a lot of concepts to get your head around (affectionalty known as gypsy curses with in our development team).
I would also be slightly concerned about performance: our App server is currently running flat out (ok I am restarting 8000 workflows at the moment). This is especially a problem if you integrate it directly into WCF using the (.NET 3.5) send and recieve activities - there are some properly crazy config settings you have to set to allow it run multiple workflows at once.
Anyway, as I said: it is useful, I would use it again, but not for another statemachine.
Also see Please confirm: Is Windows Workflow Foundation a good horse to be backing right now?
We use Sharepoint, which uses WF for its workflows. It works pretty well and is fairly easy to customize. If you need an advanced workflow, WF can support it but it will take some training to learn the ins and outs.
You could roll your own workflow, but why reinvent the wheel? WF is built into the .NET 3.0+ framework and is pretty robust, so you might as well take advantage of it.
Most people say all the good things about Workflows but I have observed that they introduce unnecessary code complexity and maintenance problems. They are suitable for a particular class of problems. other then that they need a lot of code plumbing and maintenance nightmares.