I am developing an app that allows users to post to rooms/pages, much like a forum or here (stackoverflow). I have already built out the entire app, however, I have one last obstacle to climb: How to handle updating posts for a user.
I have done alot of research into the topic, and I believe Long Polling is the way to go, at least until I get an immense amount of traffic (if that happens, I'll figure out how to implement websockets). This is because Long Polling will be easier to implement, it is more widely supported, and given that I am deploying to heroku it will be easy to upgrade my server resources quickly. Anyway, I wanted to know what the best practices are of long polling, both in terms of user interaction, and server load.
Should I automatically place posts on the page, or create an alert system such as the one here on stackoverflow?
Any and all input would be appreciated. If you think my logic is wrong in anyway, please tell me!
For a system like this we suggest using something like pusher. Check out the documentation for more details as to how to do it. https://devcenter.heroku.com/articles/pusher
Related
I'm releasing my first large app soon, and I've been thinking of writing a small app to manage the databases for my own app with master privileges, to clean up data and the like. This will just be a dev project shared with a few people within the company.
Is this something that people do?
Has anyone had any experience with this?
It feels like a good idea, but I'd also really love feedback.
I'm assuming when you say database you are not referring to coredata specifically but rather some remote database. There is certainly nothing wrong with you creating tools to help you do your job.
I think really this answer is going to come down to time management. If your database has complicated relationships,etc that a simple database editor is not going to be able to maintain or will be highly prone to human error mistakes, I'd say go for it. But, if you are just making trivial changes it might be a more efficient use of time to use a existing solution.
What is the best way to get a ballpark idea of what kind of resources an application needs if it is running on Heroku (how many dynos and what db plan you should be running)?
My non-technical friend had his site built in rails and it is currently being hosted on Linode by the shop that built the app. They aren't providing the support he was hoping for, and is interested in having me move it over to Heroku, but we are trying to get an idea of how much more that is going to cost him. I tried contacting the dev shop directly to find out what the current instance is running on, but they aren't getting back to me.
I have access to their analytics, and the current repo, so from this can I glean what kind of initial setup we are probably going to need, and if so what should I be looking for? I realize that this is very situation dependent and not an easy question to answer, but any insight would be greatly appreciated.
dyno-blitzer will help you find out how many dynos you'll need to support 1,000 users, but there are a lot of questions you need to answer in order to try and ballpark what you'll need with Heroku:
How big is the database right now? How fast is it growing?
How many users do you need to support? If you only need 5, the numbers dyno-blitzer gives you probably won't be anywhere near what you need.
How much delayed processing work is being done?
What sort of things does the app need that have to be provided through add-ons with Heroku?
Once you know these, you should be able to get a rough ballpark, but it won't be laser accurate - this will heavily depend on the app and exactly what it's doing.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Sorry for the broad question, but I'd really like to know the combination of services people are using to get great monitoring for their apps. Right now, I'm thinking of going with Pingdom + Hoptoad (+ PagerDuty), but I want to know what others are using as pretty much everything I'm deciding between has several competitors.
I want to know when my app is unreachable, unstable, or down
I want to do basic sanity check that my app is good (renders something), but doesn't have to be deep (no need to simulate a log in for a 'ping')
I want to be able to cheaply and easily add new things to monitor
I want to be able to generate my own notifications (Seems pretty standard now, but worth calling out)
I want to know when I get a lot of exceptions (the odd one here and there I'm willing to check in the morning, but 1 every few min is worth getting up for)
I want reporting
It needs to scale with multiple apps, apps running across multiple nodes, and with multiple users on the same projects.
I've seen the Hoptoad vs. Exceptional discussion. I'm more interested in what people have put together to form their entire monitoring suite. What are you using? What do you like about it? What do you not like about it?
Would really love to get suggestions!
These are the tools we use for monitoring:
Monit: http://mmonit.com/monit/
For both internal & external monitoring: apache, nginx, mongrel, mysql, sphinx, delayed_job, postfix, CPU, etc
Whenever a process goes down, its will try to bring it up. If it is not able to start a process it will notify us.
Cloudkick: https://www.cloudkick.com/
For both internal & external. We are in the process of evaluating this tool. It supports rackspace, ec2, slicehost, etc. If you use more than one cloud services, this tool might help you.
Alert Grid: http://alert-grid.com/
For monitoring our cron tasks.
Exception Notification:
Error App: http://errorapp.com/ - Its free
Airbrake(hoptoad) http://airbrakeapp.com/pages/home
Logwatch:
http://linuxcommand.org/man_pages/logwatch8.html - Sends daily report about whats happening in a server. Like new packages installed, list of cron tasks running, authentication failures, etc.
Intrusion Detection:
http://www.ossec.net/
The rails error management landscape has changed a lot since this question was first posted. But this thread came up when I was doing google searches for airbrake alternatives.
Several new companies have started offering error monitoring services for rails. The one we like at work is Honeybadger.io. Paper trail is also a nice service in this space.
Another option for error tracking and monitoring in Rails is Raygun, at http://raygun.io - it's got the usual complement of features like intelligent email notifications and error grouping, but adds nice organisation support for multiple devs and integration in GitHub, Fogbugz, YouTrack etc. It's also got Hipchat notifications so when an exception occurs your team sees it in your chat room.
Installing and setting up the ruby gem (https://rubygems.org/gems/raygun4ruby) into your project's pretty quick, too.
One wonderful way to get updates about your application is to use Exception Notification.
This allows you to get emails based on exceptions that take place in your app. It won't be a solution to all of your information desires, but if someone tries to access a non-existent page, you could get information about what they tried to access, how they got there, etc.
Hoptaud and Exception Notification are good, Heroku has another addons to use like StillAlive.
FogBugz and LightHouseApp may also help you, Lighthouse is free for open-source.
If you want to get involved deeply in Rails errors and notifications read The Rails 3 Way book's first chapter and /environment folder's content.
The best way is still BDD and TDD. Work out all redirections, add nice 404 page, use all stages for development (devel, test, hopefully staging and QA too, and only finally production), then get notifications and always check logfiles before going for production. HTH
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I struggle with finding a good medium on communication. In our jobs, it seems like it's very easy to get lost in code and lose track of time. It also seems kind of ridiculous to send out updates for every tiny task. Even though I am working very hard on getting things done, in a company that has very active communication between other branches, it tends to look bad for me when I'm not constantly updating my status. However, if I'm working on a 3-4 hour project, I'm not going to update management for every single line of code that I output.
Broad I know, depends on the people, company, etc, but what would be a good general rule of thumb for effective communication?
You need to understand why managers need your communication. I have run development teams in the past, and I am currently a coding grunt, so I have seen both sides of the communication.
Managers usually don't have time to be intimately involved in your coding, mainly because they often also have to deal with other coders in your group, testers, senior management, product mangers, customers, human resources, etc.
Your manager has committed to deliver software, and has entrusted you with delivering some of it. Because (s)he does not have time to deal with you, (s)he needs to trust you. (S)he trusts you to focus on your work and deliver the software. If you mess up, (s)he will get hurt too.
The purpose of communication is to demonstrate knowledge of purpuse, to show focus, and to demonstrate results. Here are major forms of communication.
A high-level design communicates that you know what you were entrusted to deliver. It doesn't have to be fancy. I am comfortable with rough sketches of a good data model, detailed key use-cases, and interfaces to 3rd party software.
A development plan shows plausibly that you understand the steps required to deliver. I find that delivering working use-cases is best whether I'm a manager or a coder because it is an unambiguous way to independently verify completion of useful work.
Regular status updates are good because they demonstrate focus. As a manager, I don't care if you have worked on this or that. I care about what you have delivered. From a developer's point of view, a good time to deliver a status report is when you commit code to source code control. Of course, you need good comments to show that you are delivering according to the plan. It is also a natural time to deliver because it represents an end to a "flow" or a period of being "in the zone".
Flagging roadblocks is important because it demonstrates both knowledge of purpose and focus. A good manager will help you resolve these, but (s)he has to know about them.
Dealing with bugs is a particularly sensitive time, because a bug represents a breakdown of trust because, in your manger's mind, you didn't deliver what you said you would. Being extra-communicative here is very important.
Over time, good communication will build up good trust, and ultimately it is the quality and quantity of your work that will determine your trust.
For that 3-4 hour project, you must make status updates when you start it, when you finish it, and on any code-commits you do in the middle (but if you don't, that's fine too).
Agile methodology says you should have 2 week cycles on code development. I think the same is true on communication on big projects. I try to have a major communication every 2 weeks. That includes the status I have on all of my projects and everything. This can be in the form of an email, phone call, or face to face. The only reason to communicate more often than that in my opinion is if you have run into a road block and need your managers help to overcome it or if you are working on a project or task that they need feedback on when completed. In general this keeps unneeded communication to a minimum.
Another approach is to go see your manager directly and ask them what type of communication they want and how often. In general good managers only want updates when there are major issues or on a weekly/monthly interval. You need to discuss with them what is enough to keep them in the loop but not waste your or their time.
This is an interesting question as it high-lights the verbal capacity of a programmer who ends up getting all-consumed in the process of coding that everything else seems "irrelevant", been there, done that with disastrous consequences!
DO NOT BE AFRAID TO SPEAK UP....
If there's something that is bothering you when you code...try talk to them in simplistic terms, ultimately, management do not want to know the intracies of pointer manipulation, TCP/IP stack, control re-freshes upon WM_PAINT, mapping network drive dynamically to obtain some data....you get the drift....
Speak clearly and concisely, be abstract....instead of saying something in wrt to say...pointer manipulation and seg-faulting, just say "There's some issue with the internals of the code that is causing it to misbehave, I'll estimate an n time to remedy this and get it documented and mark the issue resolved asap" where n is a quantity of time, be it minutes/hours/days/weeks or even worse months/years....
If you follow that pattern, that's what management wants to hear, if they hear the proactive approach, that is where you gain rapport and trust, and the level of trust will deepen. There is of course a 'slight hitch' with that...the management might end up piling on a load of trust which equates to responsibility for your coding....be careful there...do not flatter yourself in thinking "Gosh, they like me" at the same time burdening you with "responsibility" of the code....there's a fine balance between communicating and what they want to hear...by the way, I absolutely hate the concept of kissing one's ass in order to get ahead...DON'T!!!!
The moral and bottom line, (my being deaf and finding communication extremely frustrating and made to feel as if I'm put down or not being listened to, it's hard to deal with that because I could easily mis-interpret or mis-understand what's been said, that's my experience of it) speak clearly and do not be afraid to speak out no matter how big or small a coding challenge is or if the challenge is insurmountable and after all, that requires team effort. Share it with the team. I would be wary if nothing is shared and each in the team are in isolation and nothing being said...that's fishy....
Ultimately, lots of communication is good, but if you're in the zone (and believe me, I know how hard it is to come out of the zone once you're in it) find other ways to communicate without losing flow.
Communication can take many forms. If you've got a list of features and can check them off in some way, communication can be as simple as firing off an email for every feature. If you have an issue tracking system, communication can be as simple as updating the issue when you fix/implement it.
To update business stakeholders on your progress? I do this weekly.
To find out from business stakeholders more details about what I need? Several times a week, sometimes several times a day, always either scheduled or impromptu over instant messenger.
To talk to a project manager? As often as it takes to make me more efficient.
What behavior have you had to implement in your Rails applications that you feel could exist nicely as a plugin?
What plugin functionality have you searched for in the past but couldn't find?
What existing Rails plugins could be improved or extended, and how?
I'd like to see an engines plugin that dropped in an admin interface that provided a dashboard summary of all the models in the app, with configurable activity charts.
I once wrote a component for an application that did uploaded a zip of photos to an application so they didn't have to be done one by one, I think I may make that into a plugin when I have time, well a new version of it, the code's a little ugly.
Not easy to answer. Everyone is biased towards his own current projects. Additionally a lot of great plugins already exists.
Personally I would like to see some menu plugin for a typical data base application. E.g. where there are few user roles, and every user role has different rights. And a main menu with sub menu which depends on user's rights to actions.
A (CSS) menu is reimplemented in almost every data base application. It is rather given application specific thing and I don't know how hard it would be to implement some general solution or template.
A Credit Card Payment System
Right now, no one bothers implementing credit card payments until a site has become "production quality". Single-person projects or small startups don't bother making this at first b/c they would much rather spend their time prototyping new, hard, or interesting features.
This is bad in the long-run for everyone, including end-users, b/c the default is to offer (often innovative and really great) services for free, which means only already-funded teams or people with lots of extra time can even get to the point of making something.
If this existed, were packaged up neatly, and were as dead-simple as Rails scaffolding, small projects could default to whatever payment scheme that actually made sense -- like pay-per-use, donations, trial periods, first 5 free, etc. -- making it possible to fund the really great products out there, instead of forcing them to rely on outside funding or ads, which ruins the product.
In a real physical store, people expect to pay. If the person on the other side of the counter gives me something for free (w/o buying anything at all), I say "Are you serious??" and walk away bewildered. But online, I almost expect it. This is bad! Because now everyone expects it, and people trying to make great things can't focus on actually doing that b/c they are too busy trying to figure out how to make it great and free.
Oftentimes, there are free things out there online that I like so much that I would like to pay for, but there's simply no easy way to do it. And I'm not alone. I use tipjoy and have donated to things that have a PayPal donation setup like Auditorium, but I don't see these as adequate.
The best thing out there that I've seen is RailsKits. But as far as I understand, they aren't packaged properly so that I can add them to my site whenever I please like a plugin or gem.
I'd like to see some sort of in-built video playback/streaming. I need it for my current project.
I agree with Greg... there are lots of great plugins, and lots of great ideas for more.
I think there's always a need for more web APIs to be supported. As we go forward with API driven services and semantic web, there's tons of work to be done on that front.
http://www.programmableweb.com/ is a great starting point for thinking about what really useful APIs don't have a rails plugin or ruby gem yet.
Cheers!
Walt