Can we write the Feature files and step definitions in Swift Automation framework using XCUITEST Framework ?Is yes , Any jar files or plugins we need to install ?
I am unable to find much support in this
While this is not an appropriate question for StackOverflow, I will oblige you an answer with Cucumberish. I have used it in the past, it works, but I generally steer clear of third party frameworks as they add a layer of complexity and leave you in the lurch if they lose support.
I have worked a bit with CucumberSwift and got it to work fine, reading German-language Feature files and letting me define steps in Swift using all the functionality that XCUITest provides.
However, we have not adopted this in the end but are writing Feature files in Gherkin and then write ordinary XCTestCases that we link to the Feature files by mentioning Scenario names in comments. We develop the same functionality for three platforms and it was difficult to see how BDD tooling would work across all three or how we could make it work given the resources we have. Like Mike Collins we also felt that running without the complexity of additional frameworks was an added benefit.
Having said this, CucumberSwift seems promising, perhaps check out this discussion about documentation and add to it?
Related
How do we add our own plugin. Lets say a new add-on or feature which can be installed and used. How do we develop that? I am sorry i am new to this.
Kindly help
Depending on your needs, I suggest you check out:
https://documentation.bloomreach.com/14/library/concepts/open-ui/introduction.html
You can also create various plugins more like the native functionality. Adding such to essentials is described here:
https://documentation.bloomreach.com/14/library/essentials-plugins/overview.html
That doesn't tell you how to create a plugin however. Essentials is just a helper application, the plugin can be various things from services, to configuration, to document types, to hst components... All of that requires some knowledge of the internals of the system. Look around the documentation, you can see how to create various things like workflows, perspectives, and more.
A plugin is no more than a collection of code and configuration bundled together. It could be a frontend thing or a backend thing. So I can't simply tell you how to create them. It can be quite difficult, depending on what you want, to create a plugin. Look into the code of some plugins, you will see that it is basically a java project with some configuration that can be found by the system on startup.
You might want to ask more specifically on what exactly you want to develop. That could lead to more specific advice. It can be daunting when you are starting to work with the cms. With experience it does start to make sense.
I am looking for a easier way to manage my eclipse code snippets. I know and have used Eclipse's template and snippets features. But as far as I have found, they can only be exported and imported as XML files.
Since I use many versions of eclipse and I keep migrating between machines managing the snippets is a hassle. I am looking for a UltiSnips like method to manage these snippets/templates. Is there one?
I also looked at snip2code, but it didn't appeal to me because I sometime work offline. Also, I want to have much greater control over the snippets using version control.
Oh well! I couldn't find anything that matched the set of requirements I had. So, I've ended up creating my own.
I recently found out that Scala is an absolutely interesting programming language.
Since I'm not a real desktop application developer but more a webdeveloper I wanted to try out the play framework and if it works well for my purposes.
So far, I really like it, it seems to be easy to use and the developers really think it through.
BUT
I wanted to create an application with different templates, like an "internal", "external" and "admin" area. I already figured out to try out the "modular application" thing which seems to work good but I can't see any possibility to create something like multiple "template" files..
After a few hours of googling, I thought I should just ask..
Has anybody of you done it yet? Any tips how to organise it the best way?
Thanks a lot!
You can have as many views as required and you can also organize them in packages (under the app.views package) in many levels. All you need is just to learn how to reference required view from the controller.
Take a look to this sample schema.
In other words the most importantis clear and comfortable for you order, which you will be able to work with after 3 years without additional notes.
I started using Dist::Zilla several months ago. However, at YAPC::NA someone mentioned that they use ShipIt instead. Then today I noticed a .shipit file in miyagawa's cpanminus directory on github, so I decided to look into it some more...
My initial impression is that ShipIt has a subset of what is available with Dist::Zilla, but I don't want to jump to conclusions. So, for those who have had experience with both, what are the strengths/weaknesses of ShipIt vs Dist::Zilla?
crossposted at perlmonks
I'm the author of Dist::Zilla.
I evaluated ShipIt pretty extensively before choosing to go ahead and write Dist::Zilla, and initially they covered almost exactly the same problem space: doing all the boring grunt work of building and uploading a CPAN distribution. All of the features that Dist::Zilla now has beyond ShipIt are later additions, more or less.
If you only need the features of ShipIt, I still advise you to strongly consider Dist::Zilla, for one very simple reason: hackability. If I had been able to not write something new, I would've used ShipIt, but I found it to be underdocumented and difficult to extend. Its plugins were not generic enough and the core behavior made too many assumptions about how you'd like to work.
Dist::Zilla was inspired specifically by this problem: it turned everything into a plugin, and every plugin was given a very, very small interface so that its assumptions would be forcibly limited.
One benefit of ShipIt over Dist::Zilla is that ShipIt has (to the best of my knowledge) no plugins that will alter the way you actually write your code. This means your documentation will still look the same, you will still have a Makefile.PL, and so on. Some hackers don't like that so many DZ-based dists fundamentally change the assumptions of how to test and build CPAN code from its source repository. ShipIt will never change that.
It's possible to avoid using any such plugins with Dist::Zilla, but in general my experience is that people do use them, almost always, in one form or another.
As far as I can tell, my initial impressions were correct.
ShipIt provides functionality for releasing distributions:
keeping track of version numbers
integrating with version control
uploading to CPAN
displaying the changelog file in an editor so that you can edit it before release.
Dist::Zilla, by default, provides the ability to upload distributions to CPAN with a single command (i.e. dzil release). Dist::Zilla also has functionality for creating new distributions (i.e. dzil new My::New::Module). It also automatically generates so many of the files that I used to have to maintain by hand.
Using plugins, Dist::Zilla seems able to provide most, if not all, of the functionality available with ShipIt. It is also relatively easy to add brand new features using plugins.
I have been looking to switch to OAuth for my Twitter integration code and now that there is a deadline in less than 7 weeks (see countdown link) it is even more important to make the jump to OAuth. I have been doing Basic Authentication which is extremely easy. Unfortunately OAuth does not appear to be something that I would whip together in a couple of hours.
http://www.countdowntooauth.com/
So I am looking to use a library. I have put together the following list.
MPOAuth
MGTwitterEngine
OAuthConsumer
I see that MPOAuth has some great features with a good deal of testing code in place but there is one big problem. It does not work. The sample iPhone project that is supposed to authenticate with Twitter causes an error which others have identified and logged as a bug.
http://code.google.com/p/mpoauthconnection/issues/detail?id=29
The last code change was March 11 and this bug was filed on March 30. It has been over a month and this critical bug has not been fixed yet. So I have moved on to MGTwitterEngine.
I pulled down the source code and loaded it up in Xcode. Immediately I find that there are a few dependencies and the README file does not have a clear list of steps to fetch those dependencies and integrate them with the project so that it builds successfully. I see this as a sign that the project is not mature enough for prime time. I see also that the project references 2 libraries for JSON when one should be enough. One is TouchJSON which has worked well for me so I am again discouraged from relying on this project for my applications.
I did find that MGTwitterEngine makes use of OAuthConsumer which is one of many OAuth projects hosted by an OAuth project on Google Code.
http://code.google.com/p/oauth/
http://code.google.com/p/oauthconsumer/wiki/UsingOAuthConsumer
It looks like OAuthConsumer is a good choice at first glance. It is hosted with other OAuth libraries and has some nice documentation with it. I pulled down the code and it builds without errors but it does have many warnings. And when I run the new Build and Analyze feature in Xcode 3.2 I see 50 analyzer results. Many are marked as potential memory leaks which would likely lead to instability in any app which uses this library.
It seems there is no clear winner and I have to go with something before the big Twitter OAuth deadline.
Any suggestions?
I've used bengottlieb's Twitter-OAuth without issues.
Build+Analyse finds only one issue (in SA_OAuthTwitterController.m) and that's just a variable that has a value stored during initialization that is never read. I've not seen any leaks in my use of it. It was simple to implement and so far (two apps in the store using it, a third in development) no problems at all.
A new single-file solution is TDOAuth: http://github.com/tweetdeck/TDOAuth.
It's well-tested in that it is used in the TweetDeck iOS clients.
I recently had to implement "post to Twitter".
What I found was that none of the various projects would work out-of-the-box. They're all close, but not quite there.
Eventually I settled on OAuthConsumer, Stig Brautaset's SBJSon, with some ideas more than code borrowed from Ben Gottlieb's Twitter-OAuth-iPhone for pin processing.
I probably would have looked at MGTwitterEngine, but I didn't need to hit that much of the API - just status updates.
I seem to recall having to hack OAuthConsumer to set a few parameters correctly - that was the biggest stumbling block.
Try this Framework out for size: https://github.com/materik/meauth-ios, works well for BitBucket's API and am in progress of testing it with more sites. Please give feedback and contribute.