I've recently switched to JIRA from another bug tracking system, and previously we were not using the "component" field. The project was pretty small, so it didn't seem to need it at the time. As the project is getting a little bigger, I'm finding that the component field may useful, but I'm not exactly sure of how to split the components.
For example, let's say I have a banking application and I am adding a feature to transfer money between accounts. That feature might be classified as an "Accounts" component, but it also would affect the user interface, as well as have some security issues associated with it. It seems like many issues will have this cross-cutting concern.
Is there a best practice for determining how to divide a project into components? Are things like "User Interface" and "Security" too broad?
I'm not sure this question has a single correct answer, so maybe it should be moved to a community wiki, but any insight people can provide would be helpful here.
Components are most useful if they have obvious default assignees for each one (component leads). Another approach is to wait for a while and use labels. See if there are common labels that your users like to use, and then create components in a few weeks for those labels.
A user creating a bug can add multiple components when reporting the issue. So they could select Account, transfers and security issue (or Loan, Payments, and security issue) as all components effected by a particular bug. Any combination of components can be put together so that the development team knows exactly where this bug is occurring.
We use the component field in our company mostly to cluster the issues in a meaningful way, so that reports to these components may give you feedback which part of your application development gets the most issues, or where the most changes (with the most resulting bugs) are happening. Sometimes, the components reflect the organization of a project, then the aspect of the default assignee is a valid one (as answered by #mdoar). But even then, the overview of the project is the most interesting aspect here.
Related
I am incredibly new to Domain Models and I am trying to build up my understanding. I have created this domain model around a scenario which I will provide. I feel this model is simple and as a result, feels incorrect and might be missing elements I might not have thought of although, I cannot think of what else might need to be included in a domain model given the scenario. The idea is to demonstrate the relationship between real world class entities which I feel I have managed to achieve.
Scenario: Management Application that allows you to create users, projects, companies and issue tickets. The projects are assigned to companies, the users are assigned to projects and the issue tickets are assigned to the users. Tickets have a status which can be changed.
Changes
Implementing proposed changes. I think this is a better way to represent the idea based on the feedback returned, especially in regards to the use of composition. I have also updated the multiplicities to better represent the scenario.
Further changes
The diagram should stay as simple as possible, but not more.
In this specific case:
The two specializations of User might be too complex for the need: a User stays a User, isn’t it? If you really need to take into account differences between categories of users, and especially if the category changes over time, you'd better consider (object) composition over inheritance (or better worded for UML: prefer association over inheritance).
The associations might be too simple or incomplete. For example, before an Issue ticket gets assigned to a User, isn’t it also associated to a Project or a Company? It is not clear either if User is also associated to Company (e.g. multi-tenant cloud scenario) or if there is no such association (e.g service provider scenario, where the company is in fact a customer company).
Some associations may hide association classes, e.g. do you expect to monitor how many time a user worked on a ticket?
It entirely depends on the purpose of your model.
Some models might be created to stimulate discussion and further discovery. Some might be required for the senior stakeholders to approve. Some might be for developers to work from. Others might be for marketing material.
Your model is ok for stimulating discussion and further discovery.
Suppose I make a class diagram for a social network system such as facebook. Should the notifications and discussion messages have their own classes?
I do really think they should. I made a full class diagram for such a system, with notifications and messages as classes, but my teacher told me to exclude them. Now I am confused.
This is a very interesting question for three reasons.
1. What’s the scope?
This is a core question for any work that you’ll do in your developer career: what’s the scope of the system?
is it just core social networking functionality of one to many communication, like you had on Facebook in its early days?
or is it a full clone of facebook, including its messaging features, but also its advertising and moderating features?
If it’s the first, you’ve done too much. If it’s the second, you forgot important parts.
Rule 1: Whenever there is a doubt about the scope, clarify it with your coach/manager/stakeholder before thinking you know what there is to do.
This will avoid you the frustration of doing work that is not valued. It will avoid your future customers the frustration of not getting what they’ve expected, or paying too much for something they didn’t ask for.
2. What’s the approach?
Whenever you model some software, there’s a purpose. Class diagrams can be used for different purposes. For example:
is it for analyzing the requirements? In this domain, you will certainly have a class for Post, Comment and UserAccounts as well as associations between them. But you’d limit yourself to the “problem space” and not address the software solution and its UI.
is for the design of the system? then it probably should address how the system will work, and give some more details about how the UI will interact with the domain object. This kind of diagram might be more detailed and show the “solution space”.
Rule 2: if asked to do some modeling, always clarify the purpose. In the real world, if not asked explicitly to model, clarify the agreed approach within your team.
3. Always clarify with the person the closest to the source
(the subtitle is already the rule).
Now, is the notification a part of the UI, because they shows posts that changed and it’s part of the solution design? Or is it part of the domain, because the need for notification is independently of the chosen software solution? And because moreover notifications need to be tracked and delivered, and the they will work differently on mobile apps (push) and on web pages (pull)? As you see there is some room for interpretation, and depending on his/her arguments, the teacher is not necessarily wrong.
Conclusion
As you see, it’s not right or wrong: there are a lot of nuances between the two. There are plenty of reasons that could justify your teacher’s position. I see at least two other unrelated ones:
to adapt the time of the exercise to the average capability of your class (which would be a good sign for you)
because the teacher already know the next questions and he/she already know that notifications will make it much more difficult (which would show that the teacher was nice).
My advice: trust your teacher, and in any case engage a discussion to understand the arguments, before jumping to quickly on unproven conclusions.
Key takeaway: requirement analysis and modelling are a communication activity more than a technical activity. Whenever there’s a doubt, engage discussion with your stakeholders before seeking advice from strangers on the net ;-)
My team has been writing a dashboard application using Node.js, Twitter Boostrap, Mongo DB, and Mule for an ESB.
Recently an executive asked us to change our approach to a Portal/Portlet container like Liferay.
Some of us on the team have experience with Liferay, and we have pretty negative feelings about it. Dealing with things like full-page refreshes, portlet lifecycles, style and theming issues, and limited DBMS coverage are at the top of our list of complaints.
We see where our executive team is coming from. They have decided that they want to make the dashboard extensible and easy or easier to plug into for other groups.
Is there a solution out there which can balance the modern web expectations of users with the enterprise needs of IT professionals and executives concerned with building and extensible application with something like Liferay? Pluggable widgets are important here.
Node would obviously be our preference with something like Grails as a close second.
Thanks,
This question may not exactly be a good fit for StackOverflow's format, but I can offer some thoughts still.
If you want to stick your current platform, you need to figure exactly what features your executives want to get out of moving to a new platform. Are those features something you can build into your current platform? How much effort will that take compared to rewriting everything else? How effort will it take to learn a new skillset across your whole team? I'm sure your team can learn the new skills effectively but that still takes effort and there will be growing pains as your teams learns. If you can show to your executives that you can get the same features for a similar or less effort and that you can still have similar total cost of ownership, you can make a case to stay on your current platform.
Also I think you are underestimating what a Portlet container can do. I work mostly with WebSphere Portal so maybe thats why I think most of the pain points you mentioned really aren't that difficult to manage for me. Just because your container needs a particular DBMS to manage itself does not mean you can't use a separate DB for your custom data needs. JSR-286 introduced serveResource as a way to make AJAX easier to implement in portlets. In WebSphere Portal (don't know about Liferay), changing out the whole page content without a page reload might the most difficult on your list I'll admit though.
Modern doesn't have to mean bleeding-edge tech. And the large software products can still perform if you know how to use them right, just like any other tool.
I am still a relative newcomer to Expression Engine as a developer and a user. I am faced with the problem that a lot of my knowledge is being passed to me by users who have found ways to accomplish tasks traditionally undertaken by developers (eg product libraries) by using the channels system.
What I wondered was what people's views are on when it is best to advise a client to use this and when not to.
Let me use an example, a client wants a system which had venues where events could take place. The previous developer had chosen to use the membership system for the venues and the channels system for the events and write some custom code to attempt to knit the two together, specifically because there are not enough hooks to accomplish some background automated tasks like looking up the long/lat of the address of a venue when it is created or updated.
I am picking up after someone else's work largely but its not their fault, it was the information they were given as they were also new to the system.
In any other project this would be a master-detail type setup, events belong to venues, i'd probably write 2 custom tables, editors in the admin area via modules and then use regular custom code in the pages to display and act upon the info - this way, I could control what's happening when a user hits submit.
However, the instigating party is a veteran user of Expression Engine and instructed the previous developer in the manner of "oh, just put it all in the channels and then there's this tag and that tag and so on".
So, am I missing the point or am I right that this does not fit the channels system and when should you use channels and when not?
Thanks friends.
This question is very hypothetical and every developer will give you a different answer as it all depends on the requirement and how that EE developer rolls.
Fundamentally ExpressionEngine allows you to approach builds in many ways, none are right and wrong, albeit some are easier, some harder, others just plain daft.
Basically Channels are groups of data "entries" - these can be anything. Using your example, venues could be one channel with fields created relevant to the subject (e.g. location, size, price, etc). And another channel for events with different fields (e.g. date, type, location).
Mostly anything can be slotted into a channel. But member details are best held within the native member functionality (although there is a commercial add-on that holds member data in a channel).
You reference the previous developers approach - this could be because they used a third-party add-on that required the data to be held separately to channels, or a lack of understanding on best approach. Or just because the developer decided to approach it that way! I suspect the last developer then associated a member (venue) to an entry (event) to link the event to the venue. Basic EE functionality allows for related entries which allows you to associate 1 entry with another (e.g. Event -> Venue), or using the excellent Playa add-on, so this approach is really not necessary.
Personally I would always store the data in channels, and people/members in the native membership functionality (e.g. admin, visitors to the site, customers, etc). I'd only build an add-on (utilising it's own tables/data) to store additional information if it was way outside what EE could store.
To answer your practical question (it's stretching the scope of what Stack Overflow questions are supposed be honestly): you should use a channel for Venues and channel for Events, and the Venue field in the Event entry is a "Related Entries" fieldtype linked to the Venues channel. That's the "standard" EE way, and the most similar to a traditional database schema.
I like to post links to Secunia search results to demonstrate (in numbers) how insecure a certain CMS (or blogging software) is.
See What are some of Drupal's shortcomings?
But there was an interesting comment to this answer:
Eaton:
It's also important to note that
Secunia only publishes vulnerability
reports that are explicitly announced.
I've worked with other CMS packages
that tuck important security fixes in
minor releases with no announcements
at all. Drupal has a 15 person secteam
that reviews core and all 3500 addons
and officially announces the security
patches, no matter how minor, as a
matter of policy.
Are there any studies or articles which take this into account when comparing Content Management Systems?
I have a small number of articles bookmarked (like this one by my coworker), but they're almost all by people defending their CMS of choice from accusations of poor security. (My own comment in your post included!) One of the difficulties is that I don't think anyone has ironed out what constitutes a 'reasonable comparison' -- everyone gets annoyed at a bad comparison, but wanders off before anyone can determine what a level playing field is.
A couple things stand out that most "quick overviews" miss:
The security policy of the product's dev team
The presence of a specific person or team (depending on the project's size) responsible for security. Everyone on the project should care, obviously
Are there documented security best practices for third-party developers
Comparison of vulnerabilities by type and severity
Perhaps this thread would be a good place to brainstorm what WOULD constitute a good comparison study?
Update - A colleague has had the opposite frustration with Secunia: inaccurate and erroneous reports filed by third-parties against an OSS project. Secunia refuses to update or amend them, apparently. It's a useful service or announcements, but everything I hear makes me cringe at using them for comparison.
The other major problem with using those Secunia searches is that they include all contributed modules along with Drupal Core even when the particular announcement even though a particular security announcement might be for a module that's used by about 30 people.
In addition to vulnerabilities by type and severity, you also need to take into account "core" vs. "add-on" modules and the practice of occasionally putting multiple vulnerabilities into a single announcement (happens often).
My feeling is that some of Eaton's measures on policy are more important than specific numbers or severity of vulnerabilities.
The last good measure I would add to that list is months in the past X years where a vulnerability was publicly disclosed without any fix from the project. That's rare, but is a sign of a truly failed security process.