How does AppDynamics works internally, In my current company we are planning to use AppDynamics but teams want to know how it actually works such as How it collects data, how does it communicate and how it intercepts java transactions and other related stuff.
So I tried looking into AppDynamics knowledge base but did not get accurate technical answer I need.
Due to its proprietary nature i don't think the internals are available for anyone to view or discuss.
Below link might give an idea of how the product works at a high level.
https://www.appdynamics.com/product/how-it-works/
Related
I would like to ship some new features just for a specific group of users to better test it in production and then release it progressively to everyone, should i put IFs in my code and assign specific policies to users in the database?
Is there a better way to do it?
The normal way to handle this is have two versions of your software. The "main" version is the one most people are on, but you also release an "experimental" version which has the new features.
There are various ways to manage the software, but you should look to use strong version management practices in your source code repository, perhaps using some good branching techniques. You should avoid the two versions from diverging too much.
You can choose to invite certain users to the "experimental" version, or have them opt in but give the necessary caveats that things might not work as well, and if you have any SLAs then you might want to caveat them. If you are hoping users will provide you with feedback then make sure there is a good mechanism for that and that the users are aware of it.
If you have client software then uses will need to get hold of the new version themselves. If your software is purely server side (eg a web application or SAAS platform) then you might look at a routing layer eg in the load balancer which automatically sends users to the normal or experimental version depending on whether they are part of the relevant group.
This is a common scenario in software and you should be able to do some good research. I suggest you start by looking into A/B testing.
I am getting a bit confused about non functional requirements could anyone help me and let me know if the following seems correct
The functional requirements of this project is to create a mobile application that is:
Cross platform compatible and works on most mobile browser
Integrates a selected number of popular social networking sites in
one place
Communicates with social networking APIs
Uses login and OAuth mechanisms to authorize
Records and monitors social networking activity
Stores the data locally Displays total statistics for the user
Non functional requirements
Record statistics accurately
Fast navigation
Flexibility to choose which sites they want to integrate out of 3 and do not always have to use all 3. For example; the user should still be able to use Facebook and Twitter in the App and leave out YouTube (if they are not interested inYouTube).
App should be able to function with chosen sites.
Should be flexible in terms of being able to integrate other popular social networking sites too
Should be available to users to use anytime
if you have a look on this question, there is explained what non-functional rquirements are. In my mind the third point of your non-functional list is a functional requirment. Because this describes a functinality which the app should have. And the fourth and fith requirement depends also in the functional category I guess. But in this two cases I'm not 100% sure
Hope I could help you a bit
to really know which are the functional requirements and which are the non functional requirements, you should check it with your client ( Business Owner ),
for example ( using your data ):
- fast navigation could be a functional requirement for some clients. lets say you are developing a news feeder application, for some clients, this is a requirement and should be stated in the analysis phase my friend.
- security might not be a functional requirement, for example lets say a news feeder application, a log-in attributes might not be required.
so, my advice, be flexible about your opinions, though try to be so sure about your data before you start.
(if you are the business owner - i mean if you are the supplier of the data for your mobile application - then try to ask some of your friends and co-workers for which data might be essential for you to go on.)
I'm working for a company where I develop systems purely for internal use. There are only a few developers but we use redmine for issue tracking & feature requests. However, the only people with access to the issue tracker are team leaders, everyone else is meant to feed their suggestions through their team leader.
The idea is that this will reduce developer workload and give management more control over the features being developed. The reality is that we get emails sent directly to us from people experiencing small bugs, or feature requests.
Is this a sane way to manage user feedback or a known bad practice? I've not seen any articles which discuss managing internal issue tracking, so thought I'd ask you.
You can allow your users to access Redmine and create them a special role where they can only create new issues with a new status then the project managers or the team leaders can priorize the issues and assign them to the right people.
It will imply that your users have to be trained to use the tool to create efficient reports and search before creating a new one. But if it's an internal project it will be "easier" because you can train everybody.
It sounds sane to me. If you have end-users giving you feedback then that's a good thing. I've no experience with redmine but if there's a learning-curve associated with it then end-users may be reluctant to bother giving feedback at all. Also, you may end up with defect targets such as 'it has to triaged with X days, and fixed by Y days'. By having such an informal feedback process you avoid this. Also, your team could take a somewhat Agile approach and write bugs/feature requests onto scorecards and stick them on a wall so everybody can see them, including managers - who get to see how end-users are really using your product, and choose to fix/implement them as your team sees fit, with the priority that you choose yourselves.
Of course, your source control system will have the history of all fixes and new features!
We're looking into implementing an issue tracker for our web agency. The problem is that most issue trackers seem to revolve around the assumption that an issue is a bug, whereas in a web agency environment, a lot of the issues (request, or whatever you want to call them) are about changes and additions to a current web site.
It also seems to me that a lot of issue trackers assume that you're working on one main software project, and uses that project as the focus of the tracker. A good issue tracker for a web agency would be one which puts each separate client and their issues at the heart of the system, making it easy for them to track and report issues.
Does anyone know of a good issue tracker for the web agency workflow? What are other people using?
In my experience, issue trackers are so closely coupled to the workflow of the organisation that what works in one place may be a complete misfit in another. That said, could basecamp work for you?
We are using Gemini very flexible with the ability to have workflow at the project level.
But where Gemini really helps us is the cross project views. You can view your work across all projects with really good fitering.
Have you had a look at fixx at all? Obviously, being the developer of fixx, I will want to plug it but I know from first-hand experience that a lot of our customers are web agencies who work in a service-oriented environment and need to track more than just "software development" projects.
With fixx, you can define custom issue types (for example "change request" or "Copy changes") and track work against that type.
Unfortunately, fixx still does suffer from the "project-centric" view but a lot of our customers work around this by defining a project per client/website. So, if you were doing web/maintenance on stackoverflow.com, you would have a project called "stackoverflow.com maintenance" and would assign all your users from that company to that specific project. From there, using notifications and filters, it would be very easy for clients to keep track of progress on their specific issues.
FogBugz – it's simple by default, but extensible; it's got an integrated wiki, charts, tags, and you can even tie it to your source-control system (and they also offer their own integrated source control system, Kiln, which is pretty amazing with FogBugz).
Are you using other applications to manage the rest of your business' operations?
I ask because WORKetc has great issue tracking software, and this software is combined with other aspects of business management which can simplify the management process. So not only could you manage all support inquiries and responses in one place, but also your projects, finances, and contacts. Most importantly, it would allow you to use one central contact base for your entire company, while allowing you to reference that contact information (as well as lead information) while working on support inquiries, projects, invoices, etc.
WORKetc's support system works around email integration and simple ticket system (as well as prioritizing) and directly integrates with projects, contacts, and other aspects of the system so that you can save time while responding and managing tickets.
I think especially for the use case of a web-agency, where it's not really about bugs, but mostly (visual) feedback and all of it happens on the web, a visual feedback tool might be the thing you're looking for. Most of these tools will create a screenshot of the webpage and include the given feedback on it.
Some of them also have some kind of dashboard where you can discuss further, or have integrations to other tools like Basecamp (and some them do both).
Here's an article from smashing magazine, which describes a lot of them, e.g.: TrackDuck, BugMuncher. Another great tool the article doesn't mention, maybe because the article is a bit dated, is Usersnap – this one even includes browser extensions.
You have a good software product, so why would you make it SOA compatible?
You may want to do this to provide a looser coupling between your data services and your application layer. This will give more flexibility to reuse the service components for other products and allow you to change the underlying service architecture if need be without the need for your application to even know about the change.
Having said all that, I would first want to have an actual business use case that warrants making the switch before making the change. Changing simply to keep up with the latest buzzwords is just a waste of money. If you're starting a new project, however, you may want to consider a service-based architecture if it makes sense for your application.
In my opinion, only one good reason: you need interoperability between different platforms or technologies. Otherwise, save yourself a lot of grief and "just" make a well-mudlarized architecture - tell your boss it is SOA if that's what he wants to hear. Don't do it because you might move to or use other platforms in the future - you don't have an interoperability problem yet.
If you want your product to be integratable with other applications and your customers have actually voiced this wish / requirement then I would consider it, but otherwise it might be a big waste of time and money, especially if doing it might cause some lengthly architectural refactoring to make it work. But with no clear reason, it probably doesn't make sense to follow a trend just because others maybe doing it. Your customers will let you know when this is necessary.
That's a very difficult question to answer without more detail about your "good software product", but speaking in sweeping generalities:
If you implement an SOA scheme on your product, more developers will be able to consume the API services provided by your product because web services work across almost any development platform.
If your product is already a web application that publishes certain data, you might discover that you have readers/consumers of your data that are interested in doing analysis or building additional applications that you never thought of or may not ever have the available time to build.
The fact is: you don't need to.
SOA structure is very complicated to achieve. It requires care and organization style that I believe most companies will not have. (I'm glad if yours has such organization).
Tomas Erls talks about Contemporary SOA and Web Service First Generation. WS-I is the traditional web service style such as asp.net web services. Actually this traditional web services doesn't mean any service oriented; And what happens is people build simple web services and call them SOA.
Contemporary SOA, I believe, is an entire system structured based on services. Inside this "ecosystem", services would call each other to perform some tasks.
SOA analysis is painful and you need care. To build an ecosystem like that, you need to be prepared from the first moment.
Engineering service interfaces (contracts) is also paradigm. If you put some Lean Thinking at your belt, you should cut some desire to make state-of-art design.
If your system already works, fine! If someone will need integration in possible future which you don't know yet about it, don't do it now. But if your system is born to be consumed, them you think about it.
Best