HAYLOADED: SOFTWARE

Hot

Post Top Ad

Advertise here
Showing posts with label SOFTWARE. Show all posts
Showing posts with label SOFTWARE. Show all posts

Thursday

Dragon’s Dogma 2 review: The best open-world game of the modern day

11 April 0
Do you want to go on an adventure? Too bad, you’re going


Sunlight pours in from the canopy. Blades of grass crunch under the weight of each step. A light breeze caresses your skin and breathes life into the surrounding trees. It’s not the wind. Turn around. Go ahead. I can wait. It won’t. A creature with a toothy maw, sharp scales, and lungs of fire flaps its wings at you. Before you have enough time to think about being the brave Arisen you're destined to be, you remember that your level is still in the single digits and that the monster consuming two-thirds of your screen has six health bars.


That’s Dragon’s Dogma 2. My words won’t do justice to describing the levels of immersion that Capcom delivered in this expansive open-world fantasy RPG. Modern open-world games feel like an endless checklist of tasks to complete — they scratch that completionist itch, but they don't capture the intrigue of the world. Exploration without expectation is adventure. Getting sideswiped by an ogre popping through a clearing in the forest or diving into a pitch-dark cave to discover god’s least favorite creation — each step of your journey as the Arisen is as unpredictable as the last.

It’s been 12 years since the original, and letting Capcom cook this long delivered the Dragon’s Dogma 2 we all wanted.

I AM ARISEN

Yes, I spent two hours in the character creator. No, I spent only thirty minutes in the Pawn character creator. Yes, I’ve considered restarting to remake my character. Yes, you can re-customize your character at the barbershop. No, it costs some weird currency that I do not have access to. And yes, obviously the character creator is good.


After an embarrassing amount of time creating characters, I began my life as a Mage, which was as brief as the walk to a tavern (I’ll go into why later). I switched over to Thief and went off into the woods. There was a weird rock in a cliff face. I tried attacking it, and it broke. I climbed through the opening and found myself atop the cliff. There was a circle of rubble down in a crevice where I happened upon Runestone, which spat out another Pawn. My party was growing. I realized I was supposed to be escorted to the capital, and I completely ditched my escort. Whoops.


After reaching the capital and eventually ditching the main story objective, I fled into the woods once more. My Pawns pointed out points of interest around me like treasure chests and coins — I felt like I was in an actual adventuring party, questing in the woods. We climbed up another cliff face where I found a treasure chest, and two paces away was what looked like a golem. It wasn’t moving, so naturally it scared the fecal matter out of my body. Being the only person in the group capable of making choices, I jumped on its back and spent the next 30 minutes in pitched combat with this massive creature with too much health. It was awesome.

If you ever hear monster noises in a cave and don’t see any monsters, look up. I screamed so loud that my dog barked when three lizard creatures descended from above and tried to turn me into a juicy kebab. “I might look tasty, but I’m not for sale” is what I said to them before running up the stairs and jumping backwards to impale them on my sword. No, I will not tell you how many times I died and had to reload.


I recount these vignettes all to say that Dragon’s Dogma 2 makes me feel like a genuine explorer. In a world brimming with curiosities and monstrosities, your tools of interaction are the vocations, and each one offers new and exciting mechanics. As a Fighter, I can send an ally soaring on my shield to grapple with a large foe. As a Thief, I can kick off walls to reach heights that would normally be inaccessible.

Everything you interact with either gives you better tools or more experience, so you get better at the game without intending to. And since vocations provide unique passives that can be employed with any vocation, there is even an incentive to level each one. While I cannot take on a dragon just yet, let alone the dragon, you best believe that I’m in the woods somewhere gathering berries.


I AM NOT

Although I am enjoying Dragon's Dogma 2, certain elements break the immersion.


There’s no basic dodge or block. This is a feature I hated about the original Dragon’s Dogma that made almost every vocation feel unplayable (outside of the Ranger). While the vocations in Dragon’s Dogma 2 feel better to play, basic mechanics, like dodging and blocking, should be universal. Right now, only the Fighter can block and the Thief can dodge. It shouldn't be difficult to give these vocations a better version of the aforementioned mechanics to maintain their uniqueness. Without these mechanics, vocations like the Archer and Mage have to run away if an attack comes their way. As you might imagine, that doesn’t work often.


There’s no lock-on. I get it, that can break immersion, but as a Mage that cannot target a different creature with a basic attack, I want to throw my controller at the screen. For melee-based vocations, those narrow caves are hell on the camera and disorient my targeting. A lock-on would fix this issue. At the very least, the Mage should have a focused aim similar to the Archer. I want more control over what I’m doing, and since I don’t, it kills it for me.

The Brine. You cannot swim in Dragon’s Dogma 2, and how the game explains this is the Brine, a force that just chews you up and spits you out on the shore. This is silly. Let us swim, damn it. I don’t expect this to change post-launch, however, since there are a few platforming puzzles around the Brine. But more than that, if your Pawns fall in, they will just get murdered. That’s more frustrating when you learn that Pawns die with your loot.


Developers should also add a few quality-of-life features post-launch, such as allowing players to transfer items in bulk to party members, automatically transferring Pawn loot to the player upon dismissal, and implementing an auto-loot setting to avoid struggling with the small hit-box for looting. I would also love more map controls. Markers like caves and towns don’t indicate when they’re cleared, so it’d be nice to have a bunch of stamps to make use of in the map. And when we switch vocations, we should immediately get access to storage and our inventories to swap gear.

THE DOGMA OF DRAGONS

I’m not rushing the story, I’m killing lizard people. But I do have high expectations for the narrative of Dragon’s Dogma 2. I couldn't care less about the political intrigue; I felt the same about the original. However, what I am interested in is the cycle.


Those who played the original Dragon’s Dogma know the truth about the world, why the Arisen exists, why the dragon is destined to terrorize the land, and why the Arisen is meant to defeat it. However, given the original’s ending, it makes sense that Dragon’s Dogma 2 takes place in a parallel world.


I’ve already heard some things from certain NPCs about the “truth” of the world, suggesting that it might play a bigger role in the story. I hope so — Dragon’s Dogma dropped a bomb shell’s worth of lore on us toward the end. It would be a huge oversight not to use it.

Once I’m 100% done with Dragon’s Dogma 2 in a month (or five), I plan on writing my thoughts on the story in a separate piece. While I’m not a fan of the political stuff, the cosmological lore in Dragon’s Dogma 2 is juicy, and it deserves its spot in the sun.

BOTTOM LINE

As the latest entry in the company’s relatively new IP, Dragon’s Dogma 2’s open-world philosophy is so grand and immersive that it doesn’t even feel like a game sometimes. It might not have clicked for people back in 2012, but here’s hoping that Dragon’s Dogma 2 influences some developers just like Breath of the Wild did after 2017.


Dragon’s Dogma 2 is not without its flaws, however. In some aspects, it feels like a 2012 video game. I played the original game last year, and there are some old ideas carried over to this title that should have been left behind — taken out behind the shed and shot, to be specific.

Regardless of its old bones, Dragon’s Dogma 2 is without a doubt the best open-world game of the modern day.
Read More

Saturday

How To Deliver High Value Software Features

09 September 0
How To Deliver High Value Software Features In A Short Time Period Using Agile Scrum Process


Agile Scrum (Sprint) Process

There is an Agile manifesto that says what approaches do and don’t work for software development.

Any development process that follows the concepts Agile manifesto is referred to as Agile development. Scrum is nothing but one such process only. It is a light-weight process framework for Agile development.

Scrum is a software development process based on Agile methodology. We can say that it is a subset of Agile. In today’s rapid world, stakeholders want an immediate return on their investments. They don’t want to wait for long periods to get the fully-featured product.

As a result, nowadays new Software Development and Testing frameworks are catching momentum i.e. Scrum approach. In Scrum, projects are divided into small tasks that are to be developed and tested in specific time-frames called a Sprint (small cycles).

Literally, the word Sprint means ‘run at full speed over a short distance’. The same concept applies here. In Sprint, we aim for rapid completion and review of specific planned tasks while maintaining high quality at the same time. The Agile scrum team is handled by the Scrum master.


Scrum is an iterative and incremental framework for projects, products and application development. Scrum has become a more and more popular software development and testing framework among organizations.

Many small to large-sized IT companies have embraced the Scrum framework as this creates excellent quality products in less time than other traditional methodologies like waterfall processes.

This framework can save both the company’s time as well as money. It significantly increases productivity and reduces time to benefits relative to the other processes of software development. It also allows organizations to cope up better with the change.


Having had a basic idea of the Agile Scrum(Sprint) process now, let us move towards having a look at the soft skills that can help you in delivering high-value software features in a short time period.

Soft Skills for the Scrum Team

What Soft Skills are required for a Successful Scrum Team?

When we start our regular (Agile) sprints (Cycles of work), we usually find some of the challenges with our team members. These challenges are not part of the technical difficulties. It usually occurs with the team member’s mindset or their soft skills.

Many successful Scrum projects have taught us that the success of a scrum depends on how team members are supported wholeheartedly towards Sprint.

Let’s discuss some of the pre-requisite soft skills for the Scrum Team.

Team Spirit


Cross-functional teamwork is at the heart of Scrum. There is no “my work”, “I have finished my work” and “your work”. In a Scrum team, we find people saying things like only “Our work”, “we have completed our Sprint”.

Individuals will have a helping tendency for sharing technical knowledge. Scrum Members are always available to team members rather than being locked away behind closed doors. Scrum Master will always motivate the teams and create a Supporting Learning Environment.

The team will always be sprint-oriented and often discuss the smooth run of the sprint. A scrum team’s job is to self-organize around the challenges and the management’s job is to remove impediments to self-organization.

Communication


Good communication must exist among the team members of the development team, testing team, business analysts and stakeholders. There must be a highly collaborative interaction between the client and the delivery teams.

More client involvement implies more suggestions or changes from the client. It implies more bandwidth for communication.

Commitment

Commitment is one of the core scrum values.


Agile Teams need periodic re-energization to renew their commitments to their purpose and to each other. Scrum Masters can help by ensuring that the team embraces the concept of whole-team responsibility and whole-team commitment to deliver working software at the end of each sprint.

With the whole team commitment, the team member who has completed his tasks will help the one who has not yet completed so that hopefully each team finishes the assigned tasks on time.

Problem Solving

Scrum does not simply focus on developing just any type of end product. Instead, the Scrum method allows the team to focus on creating a product that fulfills the customer’s highest value priorities which are defined by product owners.
Transparency

Transparency or openness among team members and management gives a real momentum to the scrum team.

Scrum Master encourages people to ask for help, surface roadblocks, and give recognition to those who help others and solve problems. At the same time, Scrum Master also understands the time wasted and the impact on the team when individuals sit ideally or ignore problems.



Scrum Result

If the Scrum team follows the above said soft skills, the team velocity will tend to increase significantly. In turn, customers will appreciate the results or updates and also can react quickly to any potential problems.

The team can deliver high-value software features in a short time period and the team can contribute towards changing business conditions.

About Author: J.B.Rajkumar is a Certified Scrum Master (CSM) with rich experience in the Agile/Scrum framework. He has worked as Corporate Trainer, Project Lead, QA Manager and QC Manager. He has implemented Scrum in no. of projects in his current organization.

He is a frequent speaker on Agile/Scrum for International Conferences, Colleges, Universities and Software Industries. He conducts training on Scrum and Agile Testing. Presently he is with Automation Practice, one of the top MNCs.
Read More

Friday

Role Of Business Analysts In SCRUM

08 September 0
Role Of Business Analysts In SCRUM And Why Is A QA Best For This Role?


Responsibilities of a BA

There are several Roles of Business Analysts in Scrum and there are certain responsibilities to which a BA should adhere.


A few selective ones among them are mentioned below.
  • Grooming product backlog based on the prioritization provided by the product owner.
  • Analyzing customer needs and finding solutions to address them.
  • Creating requirements in the form of user stories with appropriate acceptance criteria.
  • If in case the user stories have already been created by the product owner (with acceptance criteria), then review them to make sure that all business rules are covered and the acceptance criteria meet the user story functionality.
  • Work with product owners and stakeholders to understand the scope, suggest improvements to the requirements, etc.
  • Prepare documents like wireframes, design flow, UI, etc., as and when required.
Apart from this, a Business Analyst is an important participant in the brainstorming sessions when the team meets to discuss the upcoming sprint backlog. The BA guides the team, helps them to understand the requirements, and even at times has to approve the implementation.


He also works closely with QAs like analyzing test coverage, converting real-world use cases into test cases, providing insight to test complex functionalities, etc. BA also participates in planning meetings to help the team in estimations by helping them to understand the flow, complexity, and dependency.

BA has to always keep learning about the new trend that is going on in the market, keep innovating and stay updated about the business area for which the product has been made.


Business Analyst as a Product Owner

Depending upon the customer and the company, it happens that some companies have the Business Analyst as the product owner. BA is the contact point for all queries. BA then becomes the mediator between the team and the stakeholders.


BA has to understand the requirements of the stakeholders, their thinking about taking the business ahead, and what (and how) the business should grow. Then based on the requirements of the stakeholders, the BA must create the documents, user stories, prioritization the stories, help the team understand them, answer their queries about the same, etc.

The most important thing to note here is that this is advisable when the BA is physically available and is not geolocated to a different time zone so as to avoid the ‘gap in communication’.

If the BA as in the product owner is geolocated to a different time zone, then it is not possible to approach him every time and the only way to communicate is by email or chat or call, hence this may result in lack, gap, and even miscommunication at times.

As per my experience, this should be followed when the BA is sitting in your office, next to your team so that your work won’t hamper, and (s) he will be easily approachable. From a BA’s point of view, they own the product on behalf of the stakeholders/customers, make appropriate decisions, and even need to learn new skills which may include learning some technicalities of development.


Having a Business Analyst as a Product Owner is an added advantage because the BA is able to understand the product very well, and prioritization and scoping of tasks can be negotiated as well.


Business Analyst as a Team Member

The other option is to have the Business Analyst as a team member because the Product Owner will not be available every time. If the Business Analyst is a team member then they can help their peers with backlog grooming.

Having a Business Analyst as a team member is more advantageous because the technical team finds it easy and comfortable to communicate with the BA for clarifications or discussions. BA is also working closely with the QA team for testing i.e. analyzing the coverage, use cases covered, any hidden requirements, dependability or effects.


Sometimes the acceptance criteria written by the product owner may be vague and not clear, then as a team member, it becomes the responsibility of the BA to write elaborate and well-explained acceptance criteria. If the team needs more information, then the BA can also create wireframe documents, flow documents, etc. to help the team understand the requirements.

In large-scale projects where the modules are distributed among teams, having a BA for more than one team is also an added advantage. Since BA is the same across teams, (s)he can think about the interoperability of the modules, how new features or updates will affect the other modules, etc.

Thus, this would help a great deal to the technical teams to consider such aspects as not always do the user stories or acceptance criteria mention such.


Importance and Role of Business Analysts in the SCRUM Team

The role of Business Analysts in SCRUM is undoubtedly very important in the success of a project. Their involvement starts right from understanding the customer’s need for a Sprint Demo. They are the first point of contact for the technical team for clarifications. They are even more important in the initial phases of a new project and the projects which are large in scale.


The Product Owner will not always be a good writer, sometimes they come from a technical background and hence it becomes the responsibility of the Business Analyst to write the stories, acceptance, wireframes, etc.

In my project, our PO was not so good with documentation and even the user stories written were never more than 2-3 liners while the acceptance criteria were only a 1 liner. It was the Business Analyst who used to modify them, make them more explanatory and elaborative.

Even at times, it happened that our PO wrote user stories that had 21 or more story points, and hence the Business Analyst had to spend extra time & effort in breaking them down and prioritizing them with the Product Owner.


You can imagine what would happen if there was no Business Analyst and your Product Owner has created a user story like “As a customer, I want to perform all banking operations for my account”, with acceptance criteria like:
  • The customer should be able to log in.
  • The customer should be able to make transactions on my account.
  • The customer should be able to download my historical statements etc.
Now, in my opinion, this user story would hold even more than 34 story points, hence there is a need to break it down further. Things will worsen for the technical team if the proper flow diagrams and UI screens (to be created) are not provided.

This would lead to a failing sprint, and in turn, a failed project. Unless the Product Owner is a trained/practiced Business Analyst, there is a need to have one on the team.
 
Why is QA the best fit for this Job?

QA is a person who verifies the proposed solution for a problem/requirement by testing it. Hence the Business Analysts / Stakeholders / Product Owners are very eager to know about the feedback of QA. The involvement of a BA in testing is little more than what it is in development.


A Business Analyst works closely with QA in reviewing the test case coverage which provides insight into hidden flows and requirements/effects. Thus this kind of knowledge sharing (by the BA) makes them understand the product functionality, the business rules, the customer expectations, the flows, dependencies, and everything completely.

QA always tests from the point of view of the end customer who would be using the product, hence the chances of helping the customer for improvements, enhancements in the product are more (when compared to a developer). Developers develop the product for the given user story and the set of acceptance criteria but do not always think about how a customer would use the product.


In development, the implementation of a product, the flow, and the rules are well defined but testing is completely based on logical thinking and the ability to think from the point of view of the end-users.

QA can start getting into the role of Business Analysts in SCRUM because of the lot of opportunities that are presented in the day-to-day work.
Read More

How To Improve Software Quality And Reduce Risk

08 September 0
Continuous Integration Process: How To Improve Software Quality And Reduce Risk


Continuous Integration Process

Let’s retrace back to the CD pipeline diagram discussed previously. The red circle will be our focus in this article in order to understand the CI process.

Even though the CI process may seem very development centric, it’s vital for QA engineers to get an overall picture and adapt accordingly.

Before we proceed any further, the following terminology is important to know:
  • Source code or version control system has all the code related to a project/feature.
  • Mainline: The most recent state of the code in a version control/source code system
  • Local Copy: If you have had experience with working with an Eclipse-like IDE, you will know that you can import a project’s codebase into your local machine at a particular location. That location in your local system is the “local copy”.
  • Check out: When a developer begins to work, the common practice is to import the latest source code onto the local copy. This activity is a “check out”.
Say there are two or three development engineers working on a feature and are using Continuous Integration.

This is how the sequence of events would appear:

1) On the local copy, the developer builds his code for the new feature.
2) After coding is done, he might write the required automated unit tests to test his code.
3) A local build is run, to ensure that the newly added code doesn’t break anything.
4) Once the build succeeds the developer checks if any of his peers made any new check-ins.
5) In case there are new incoming changes, he has to first accept those incoming changes to make his local copy most current.
6) Synching with the mainline might result in some conflicts due to the newly merged local copies.
7) If a conflict arises, it is fixed so that the changes are in sync with the mainline code
8) After step 7, the code changes are ready to be checked in. This is called “code commit”.
9) After commit, another build pertaining to the source code (mainline) is run on an integration system.
10) This now is ready to be consumed by the next stages.

Continuous Integration Tools

It is dependent on each organization on what kind of CI tools they use.

While some of the tools like Hudson, CruiseControl, Jenkins are popular choices, there are many other tools that provide similar capabilities in addition to their own unique features.

The decision of choosing a CI tool depends on a lot of factors, such as:

Being able to integrate with configuration management tools
Easy, customizable reporting
Integration with automation tools, etc.

CI Benefits

1) Errors detected early: If it is an error in the local copy or code checked indirectly without being synching to the mainline, a build failure will occur at the appropriate stage. It forces the developer to fix the bug before proceeding further. QA teams will also be benefited from this as they will mostly be working on stable builds.

2) Decreases bug accumulation: Bugs are inevitable; however with the use of CI the piling of bugs is reduced greatly. Based on how effective the automation is, the bugs are easy to find early and fix, greatly reducing risks.

3) Setting the stage for Continuous Delivery: CI reduces manual intervention because build, sanity, and other tests are all supposed to be automated. This paves way for a successful continuous delivery.

4) Increased transparency: CI brings in a greater level of transparency into the overall development and QA processes. There is, at all times, a clear indication of what tests are failing, causes for failure, defects, etc. enabling you to make factual decisions on where and how to improve efficiency.

5) Cost-effectiveness: Based on the above points of early error detection, less bug accumulation, more automation and clarity in the overall system, it is needless to say, that cost is optimized.

CI In QA – A Point Of View

This is a natural and logical extension to our previous discussion. These factors have to be in place to be able to use CI for testing.

1) Initial tests: We left off at a point where we now have a good build after a code commit. The code commit should trigger some automated tests – smoke or sanity checks certifying that the build is now ready for QA.

2) Automation Framework: To stay true to CI, every QA team should invest in building a test automation framework that automatically triggers tests that uncover not only feature specific shortcomings but also identify framework enhancement requirements (for current and new tests).

3) Parallel testing using Automation: A robust automation framework facilitates parallel testing and replication of production with various configurations. It also yields better test coverage and fewer bug escapes.

For instance, if support for two or more browsers on certain Operating Systems is required, then tests that simulate the needed configurations can be set up and run in parallel, thereby drastically increasing test efficiency.

4) Automation across different types of testing: Continuing the previous point, automated test coverage should include different types of testing – functional and non-functional tests – such as stress, load, performance, regression, database, acceptance, etc.

5) Bugs: This is particularly interesting because even the logging of bugs can be automated with a CI system! You can poll for certain kinds of errors coming up in the logs and on encountering them, a bug is automatically logged. A typical example of this situation is auto-logging bugs for nullPointerExceptions observed in a server trace log.

CI Implementation And Best Practices

Continuous Integration aims to have a drastic drop in the degree of errors during software development through feedback mechanisms, automation, and quick bug fix turnaround.

Although it may seem too ambitious for a process to achieve all of this, it can certainly be a reality with some of the continuous integration best practices described below:

1) Shared repository to maintain code: With Agile evolving rapidly, it is a given that there are multiple developers working on different or same features of a product. It is therefore absolutely necessary to have one repository that will be able to capture the timeline of changes that all developers are making.

Version or source control tools help you create different development streams and better prepare the teams to be able to respond to these needs. They also help in keeping all the artifacts needed to perform a complete build (libraries, properties, environment variables, test scripts, etc.) in one place.

2) Trigger automated builds through CLI: Builds need to be automated to a point that they can be triggered through a CLI.

For example, you can use ANT and Maven to spin a build. This means that one should be able to connect to the build server, load the required assets from an online or local repository, compile and run the whole build with a simple Sometimes in a large build, some of the artifacts would have already been downloaded as part of a previous build. Therefore, the build tool must be able to gauge and download only the needed resources.

A build may successfully compile but that doesn’t mean it would be suitable for testing. Therefore, it’s also important to have some tests incorporated as part of the build, in order to discover any obvious bugs early.

3) Frequent code-commits: The beauty of this system is that even with multiple developers, code conflicts are easily caught. This is because each developer has to update his local copy before he can commit. If this is done daily or as often as possible: The more commits = the more updated local copy is with the mainline. The more updated the local copy, fewer conflicts. Fewer conflicts = stability!

4) Quick Build time: A longer build time defies the whole purpose of Continuous Integration because it won’t be possible to get ongoing fast feedback. Secondly, frequent code commits will become increasingly difficult. How do we combat this? This takes us to the next best practice of having Staged builds.

5) Staging builds: In order to expedite the build process, the build pipeline could be broken down into smaller chunks and executed in parallel.

6) Run mainline build on integration machine: In the Continuous Integration process, we had talked about running a second build pertaining to the mainline code. This build happens on an integration machine. You might wonder why? As the testers, we encounter situations where bugs are seen only on a particular environment and not in another. This is exactly the reason a mainline build is run on an integration machine.

Sometimes integration machine will spring up surprises that didn’t exist in a developer’s local system. Human errors such as not synching your code with the mainline will also show up here. Therefore only once it builds successfully here, the commit can be declared

7) Create a duplicate of Production System: As the testers, we’re so familiar with environment-related defects. Production systems have their own configurations in terms of database levels, Operating system, OS patches, libraries, networking, storage, etc.

It is a good practice to have the test environment as close as possible to the production system, if not an exact replica. Any major discrepancies and risks can be easily identified this way before it actually hits production systems.

8) Automating Deployment: In order to get to the point of running different kinds of tests in a CI model, the test setup has to be done as a prelude. As a best practice, you could have scripts that automatically setup the needed runtime environments for testing.

9) Publish build locations: With frequent builds getting spun, it is important to make all the consumers of the build know where the latest build can be found. A repository where builds are published can be shared with all those involved. Likewise, build, and initial sanity results should also be published, so that people can see what integrations or fixes have gone in.

Conclusion

Application of CI in test organizations proves to be invaluable for its automation scope.

As we’ve seen above CI reduces testing effort with a promise of greater accuracy. This is much needed for the Continuous Delivery process as a whole.

Continuous Delivery and Continuous Integration are definitely evangelizing Agile. Adopting these procedures will take you a step closer to respond to rapidly volatile and dynamic markets.

Let us know if you have any other best practices/suggestions for continuous integration.
Read More

Popular Posts

Post Top Ad