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.
Related
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 :)
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
As one who is relatively new to the whole support and bug fixing environment and a young programmer I had never come across a bug that only occurs in the Websphere environment but not on the localhost test enviroment, until today. When I first got this bug report I was confused as to why I couldn't reproduce it on the localhost test environment. I decided to try on the Websphere test environment to see what would happen and I successfully reproduced the bug. The problem is I can't make changes and build to the Websphere test enviroment. I can only make changes to my local environment. Given this handicap what methodologies exist for resolving these kinds of bugs. Or are there even any methodologies at all? Any advice or help on how to approach issues like this?
Campaign for full access to a test environment. Being able to tweak things, redeploy and retry makes a huge difference. It's entirely reasonable to explain how not having access severely restricts your ability to do your job.
Make sure you've got sufficient logging, and make it configurable. Make sure you keep the logs for long enough to track down a problem reported by a customer even if it happened a few days ago.
When you finally diagnose a problem and why it only happens in a particular environment, document it and try to persuade your local system to behave the same way - that should make it easier to diagnose another symptom of the same problem next time.
In short, the methodology is to isolate and understand the differences between environments and which one or ones might be causing the issue.
Check your local build. Make sure it the same version (code and database) as Test and Prod. If it is, what are the environment differences that could effect the issue you are seeing? (Multi-core, load balancing, operating system version, 3rd library version). Don't run locally in the debugger, make sure your running a release build (if that's what is on Test and Prod) and maybe even do a local deployment rather than building from source.
Check to see if it is particular data that might be causing the problem. If you can, pull a copy of the database back from Test onto Local and see if that enables you to repro the problem.
Check with other developers. See if they can repro. the issue in their environment. Check with your QA guys, get their thoughts on what might be causing such an issue (often times they will have seen "similar" issues and might give you a clue).
At that point, if nothing helps, I generally go into a deep state of zen to try and understand what I am missing. But, there must be a difference, you just have to find it.
The Scientific Method always applies-- check your assumptions first. If the systems are different, the problem might reside in some sort of implicit default being different, or a different implementation of some function.
In all debugging processes, localization is the key. You gotta isolate the area of the problem first. If your OS, patches, libraries, and the main software itself are all identical, then it's probably the system settings (limits for sockets, file descriptors, etc). If you know you have enough inodes, space and memory left, then it's not a resource issue. If the computer is barely responsive to your interactive prodding, your load is too high, or you have some runaway processes. Remember what every process needs to run, and make sure they got what they need.
It can be also code just can't deal with the load of the production system. Locking mechanisms are a very popular cause of problem in production vs dev/test systems, simply because you can't generate enough of test cases that you get for free in production.
Logging can be easily overlooked, but I also like to add a lot of debug values into the code, to make debugging easier. I cannot even count how many times some environment variable, path, or broken symlink have ruined my day, just to realize that it would be a trivial fix if I looked at the values of variables while running, not just looking at the static code.
If all else fails, ltrace and strace are the best way to really look at what's going on under the hood. They're not easy to read, but once you get used to how spot and interpret return values of some syscalls, you gain a very powerful debugging tool.
I'm having trouble deciding if I want a project of mine to be web-based (as in a web-app), desktop-based (a desktop application), or a desktop application that can sync or connect to the cloud.
I don't know if anyone else would have an interest in this application, and it's only going to be for me, so I'm leaning toward desktop application. If, for some reason, I finish it, release it, and people actually like it, I might see about making it sync to the cloud as well (think v2). But I'm not sure how hard it is to make such a radical change, and I don't want to end up with something good that is useless because I made a poor choice before I even started the project.
Is there any sort of guidance for this? Any rules of thumb or best practices? Any personal experiences?
If the language matters, I'm thinking about Java simply because I'm most comfortable with it, and it would easily allow me to share it with my friends for testing and if I get stuck and need help from someone else in person.
I generally ask a few questions:
Can it even be done on the web? Something I did not too long ago involved an image editing component, and had to be a web app. It involved much pain to get this work, and a desktop app would have been a far better way to go.
Will I need to access it from anywhere? Yeah you could load it up on a thumb drive, but the web is far more feasible in this case.
Will there be multiple users? This could go either way, but "long tail" stuff usually means web.
What tech do you want to use? The latest and greatest WPF based UI? Desktop (yeah yeah, silverlight, let's not go there ok?). The brain dead stupid easy user management of Django or others? Web.
If it were a web app, will you need to worry about common attack vectors like SQL Injection, XSS, etc? A desktop app has its own issues here too, but tend to have less exposure.
How resource intensive is it? Will 10 users kill performance of a web server?
Versioning on the desktop can be a pain, whereas with a webapp everyone is on the same version. This can bite you though, see the New Facebook user pushback.
EDIT:
Cost can be a factor too. A web app with a database backend typically means a web server. If you want to stick with, say, the Microsoft Stack, you'll need licenses for SQL Server which can get pricey. Open source is cheaper, but may not be an option in all cases. "Serving" a desktop app is generally cheaper.
If you release as a web-app, you won't have to port it over. You'll also have access to it wherever you go.
I base my choice on the GUI mostly. If the GUI is going to be complex, and (needs to be fast or will have aspects of it that will take a lot of time to process) then I will go with the Desktop. If it is simple, and will always have small data sets to work with at once, the I will go with the Web.
I have worked on an app that was made as a web app, when clearly it was better suited for the desktop. It was a massive failure. I don't know HOW customers put up with it, cause I certainly wouldn't have used it. The desktop version (which took over 6 months to re-write) blew the web version out of the water.
That being said, I have seen some nice web apps.
All I can suggest are several factors that would be relevant. How you determine the answer and weight for the factor is up to you and other circumstances:
What is your audience? Do you have any control over them?
How complex are the interactions you expect to implement?
Do you require near real-time data updates?
How often do you expect to update the application after the first release?
Do you expect a well-defined set of client platforms, or can you not predict that?
Note that your choices also can include a Java WebStart application, which mitigates some of the disadvantages of a typical desktop application.
I'd say that most applications should be desktop-based. The advantages are faster and more fluid apps.
You should only create a web application if there are obvious benefits from it, like access from everywhere. (If that's necessary for your app.)
A downside of web applications can also be that it is dependent on the developer, if you quit supporting it all your users (if you'll have any) can't use it anymore. Furthermore, there is a chance that users are not willing to store their data online.
Ultimately it depends on what kind of an application you want to write. Even if you create it as a desktop-app, you can later on rewrite it for the web. Often a 2.0 version of software needs almost complete rewriting anyway.
Sometime web can be good and sometime not. We are in a new wave that go in the web but do not forget few things:
GUI in web is more complicated because of multiple browser
People who need to work on your system might not like working the whole day in a browser
Web can be slower for some application (image editing, hard job that require a lot of CPU)
Rapid Gui like Visual Studio for winform are faster than for web
But web has many advantage in the deployement and in the portability. If your system is well structured you could make both or change to one to other later with something build with MVC. Just change your visual and you will be fine.
If this were an application to be used my multiple users, with shared data, you're probably going to want a server anyway. In that case I'd lean towards a web application.
Otherwise you've got the complexity of syncing data between the desktop and a server.
Two important questions not on the list so far:
Will the first version have any features that need lowish-level access to hardware?
Will future versions have any featuers that need lowish-level access to hardware?
It's pretty easy to answer the first one, but giving the second one some thought can save you some headache down the road.
My default choice is to go with a web solution, as it's easier to deploy and generally multi-platform. The only time I go with winforms apps is when there are pressing security, performance, or functionality issues that require it.
Previously you'd have written a desktop application, as tool were better for that and you'd have written it faster. People used to want web apps, but always ended up with desktop.
Nowadays things are different, you can write a webservice just as quickly and easily so there's no reason not to go web-based.
The advantages of web-based are flexibility, scalability and ease of deployment. It won't be as responsive as a desktop app could be, but that's not so much of an issue if you think about your design.