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 8 years ago.
Improve this question
I'm about to start building a Rails app that will eventually need to vary CRUD access by user (i.e. which pages do they see, which can they edit, etc).
Is there a best stage of the development cycle to incorporate this?
Part of me feels like it should be the very first thing, since almost every piece of the interface will in some way rely on checking the user's ID, and it will be an inherent part of the DB structure.
Another part feels that this would overcomplicate things to start out with, and that I should instead build the core parts of the app, then layer on the authentication/authorization later.
Are there any best practices around this sort of thing?
I would say that if your system will rely on some kind of authentication... Why wait?
Let's say that you start developing your application without the authentication layer but at the same time you know that at some point you will have to do it. That means that at some point you will develop the authentication layer, and most likely you will have to refactor what you have already built to adapt it to this new layer.
Also, to try to convince you a little bit more...When you say:
I should instead build the core parts of the app
You should consider that the authentication module might be a core part of the app too...
I prefer to do it early, but you really have roughly the same amount of work in front of you regardless of when you do it. It really a matter of opinion on when you prefer to do it.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm a bit new in rails development I'm modeling a website with few resources and so far so good. But here is my question:
I would like to allow the admin users to manage information show in most of the pages: Application name, telephone number, address, default email and this kind of things.
My current idea is make a model Property with name and value, but somehow I'm not convinced about this approach because I'll need to access the database to get this values for every request.
Thanks everyone for your time! :D
This seems like an OK approach. If you implement caching, it no longer will hit the db with every request, and honestly it probably isn't really that big of a deal even without the caching. Build it the way you need, and optimize afterward, if necessary.
With all this being said, it may be worth considering how much things like the phone number are going to change, and balance the cost of developing a dynamic solution against the time it would take to change once, 3 years from now (if the number ever does change), in a partial.
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 6 years ago.
Improve this question
In most ASP.NET Mvc tutorials, you see people creating simple models and then scaffolding controllers with views, using Entity Framework.
In most tutorials you will also see that they create a new DbContext class which will have the DbSets. I understand that this is a good thing to do for educational purpose, to help the person understand how it works.
But the account system that comes with a default Mvc project always links to "DefaultConnection".
Some tutorials will also make use of the account system to advance further, but that means that at this point you would have 2 databases running to support your web app.
one for the account info
one for the details of your model(s)
Is this the correct way to work? or do most developers/companies just use 1 database for both of these?
My reason for asking is because i found this tutorial which uses both of these aspects and works on 1 database and it is the first time i see this being done.
There's no right or wrong way. You need to evaluate the requirements and time lines for your projects and decide which options suits you best.From personal experience, in all the projects I worked on, the account info and the models reside on the same database.
Remember that if you have two databases you will need to create two data contexts to access them.If the database needs to be moved to another server, you would need to move two databases and change the connection string in two places, also the maintainance and upkeep on the DB would need to be performed in two different places.It's really a maintainance headache and should be avoided in my opinion unless your requirements have some compelling reason that you should place account info into a separate DB.
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 8 years ago.
Improve this question
I am making my first RoR application and I am a bit confused with planning it out ahead of time.
It will be an anonymous imageboard (like 4chan) where people can make threads across multiple boards and attach images to their posts. They won't need to register and can post anonymously.
Now I am not sure how to implement it, I am guessing there has to be an admin user who will be able to create new boards and delete threads, right? So far I have planned the following controllers:
PostsController
UsersController (can I define the admin user here or should I make a separate controller?)
ThreadsController
BoardsController
Does this seem okay to you?
Thank you for your time.
Planning ahead of time for everything you will need goes against what Ruby on Rails philosophy is to begin with. Ruby on Rails firmly believes in Test Driven Development or TDD.
In that sense, the tests will actually drive your design, starting from unit tests all the way to functional testing. I.e. don't try to anticipate all controller/models from the start. Try to use TDD to let you help design the system, it is a good practice and if you don't know 100% the path you want to follow, it will help you somewhat make your system a bit more robust because of the test harness.
Try to follow this before you start your application. Good luck.
http://guides.rubyonrails.org/testing.html
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 9 years ago.
Improve this question
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.
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 6 years ago.
Improve this question
I'm just about to rewrite my personal site/blog using ASP.NET 4/MVC. I usually use my private Subversion server for version control, but for this project I'm intending to use Git/GitHub —I've been using Git more and more recently and prefer the way it works. I'd also like to make my code open-source in case anyone else wants to use it to learn from.
My question is this: if I make the source code of my personal site publicly available on GitHub, am I exposing myself to an increased risk of security breaches?
I'm not concerned about intellectual property here, just about security—whatever code I write will be fairly basic anyway.
I realise that a) the open-source community leans very much toward the white-hat and b) my tiny web site is not by any means a worthwhile target.
Having said that, if I'm publishing my code and I make a mistake which results in a security hole (and I'm positive that at some stage I will, nobody's perfect), it only takes one malicious person to exploit it rather than letting me know and I'm screwed, aren't I?.
If you open-source it, it has a higher chance of being hacked, but you have a much higher chance of being told about it. If you don't, you may not get told about it if it happens.