The situation is as follows:
I am trying to define a path in which a certain character travels in a game. This can be done by typing all coordinates for such path. However, this requires a lot of testing, recompiling, as you try to view such path in the product and see if it is what you wanted. This is very tedious
Clearly there is no Graphical Interface built in for every purpose, and obviously also for this case. Then, I proceed to built another application/ another few files that serve as a custom graphical interface for my path class: for editing paths by coordinates and change it interactively.
This does not really cause a problem. However, such an application does not fit in the app, nor make sense to be an application just for programming a specific class. Additionally, if I want to have an application for each of my more complicated data structures, it becomes very messy and hard to manage.
I recall that there is a playground feature in swift. This is perfect for me as it is interactive. And I am thinking:
Is there a way to programme an playground-similar application inside the same project?
(Since I demand programming to be pretty) Can this be done without switching to different projects just for this purpose? Is there such a feature?
Equivalently, is there a way to programme something that helps programming within swift, such as an extension for swift?
Again, I emphasis that, this is needed only for saving troubles and making an application more self-contained.
Turns out to be a stupid question. There is obviously an option in adding a new playground file to existing project.
Related
I'm total newbie with Laravel, so the question might not be the most intelligent, be gentle, please.
I'd like to use an Open Source application made with Laravel. However, the application does not fully suit my needs, hence some customization is needed.
Naturally, I don't what to change the application files and also want to keep all my files separated.
In other PHP-based applications there are typically methods to customise the app without touching any other code. Also, it is possible to have own code nicely in one place. For instance, Wordpress has a theme concept, child theme concept, plugins and hooks in code (filters and actions). In Magento we have a simple method of overriding a core file by copying it to local code pool, as well as a more sophisticated dependency injection, which allows to override any class anywhere.
I've been trying to understand what is the correct way to customise a Laravel application in such a way, that my own modifications are separated from the base application and e.g. updating the base is possible.
Please guide me, or give pointers on how to do this.
Sounds like Packages might be your best option.
https://laravel.com/docs/master/packages
They let you customize very much in your application without touching other parts of the code, as well as keeping it separated from the other parts of the application.
Here's a getting started guide on packages:
https://medium.com/#lasselehtinen/getting-started-on-laravel-package-development-a62110c58ba1
What I'm trying to do is test a Swift file frequently after making tiny changes to the file. The file may contain one or more structs and classes.
I don't care about a concept of an "app" because this is purely an academic exercise to practice some new concepts I've learned. I just want to test the file and don't care about the app and anything related to the app.
You may be asking why? Speed. I want it to be really fast to test, right now it takes a few seconds for the most trivial example. I see it does a lot of work to build the targets:
You should try a Swift Playground.
Here is the description at developer.apple.com/swift:
Interactive Playgrounds
Playgrounds make writing Swift code incredibly simple and fun. Type a line of code and the result appears immediately. If your code runs over time, for instance through a loop, you can watch its progress in the timeline assistant. The timeline displays variables in a graph, draws each step when composing a view, and can play an animated SpriteKit scene. When you’ve perfected your code in the playground, simply move that code into your project. Some uses for playgrounds include:
Design a new algorithm, watching its results every step of the way
Create new tests, verifying they work before promoting into your test suite
Experiment with new APIs to hone your Swift coding skills
I want to implement unit testing in my Xcode project, and would like to run tests without requiring the application to be started.
Reasons for this are, I have a core data based document app, that also uses a cvdisplay link to control continuous rendering in a background thread.
It strikes me that I do not need a running application to test core data datamodel functionality, this should be distinct from view stuff anyway. Also I would like to isolate and performance test my background rendering processes, something that seems very difficult with the app running, but could easily do without the application running, just getting the right classes and feed it the correct data.
I've seen other questions that have answers for Xcode versions before six, but the answers don't seem to work for the current version.
The docs now make a distinction between application and library tests. Library tests are run against library targets.
I'm not sure i want to reorganise my code into distinct libraries at the moment, and would prefer to avoid it or fake it somehow.
I saw somewhere an openradar relating to this in ios, but I'm interested in osx.
Has anyone any insight into this?
EDIT : Learning to cope with the existing setup for now, testing with full app running, I can run some checks on that, then I close all documents and shut down the display link.
I can then run tests creating my own persistent store coordinator, in memory datastore and context, as well as testing my rendering classes without fear of conflict with the other display thread.
I'm now running into troubles with linking sources, I just can't seem to get it right, I fiddle with settings, it seems to work for a bit, then suddenly stops building again with Undefined symbols for architecture x86_64: errors, either that or problems linking with 3rd party private frameworks. I look through the web, change a few things, it starts working again. Then I add some tests, importing more of my classes, things stop working again.,.. Infuriating
EDIT 2: Pretty much all sorted now, but maybe not terribly efficient. For each test case class, I either open or close documents and start or stop the display link in the +(void)setup method. I don't do anything in the +(void)tearDown, and let the setup decide how to proceed based on the current state.
Although this means it's possible to flow from one test class to another minimizing document opens and closes, there doesn't seem to be a way to order the tests so that I could group them together.
BTW, I also solved my mentioned linking troubles (XCode 6 Testing Target Troubles), not really relevant to this question though.
It sounds like you landed on the standard solution: Give your app a way to tell when it's being stood up for testing rather than use, and then have applicationDidFinishLaunching: not do any of your usual launch-time behaviors, but leave it to specific tests to provide any setup they need.
You might benefit from creating multiple test suites to deal with different expected conditions, like all the tests that work around a specific document being open.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
I'm writing a web application in Go. So far I've written all base libraries I'm going to need for now and that worked out just perfect. The package structure is really handy in that aspect.
Now I'm at the point where I need to start writing the application itself, the business logic. I'm a little lost of how or where this code should go.
I've watched and read pretty much every application development tutorial/walkthrough on the official documentation page and they always write the entire domain logic in the main package/namespace.
Is this the way to Go (sorry, had to) or was it just for the sake of simplicity?
Putting the business layer into packages feels uncomfortably wrong in my opinion.
No, it does not have to be all in the same package. You can easily make a new directory, put your code for that package there, and import it from your main package. It's simple as that.
You may want to look at go-tour as a simple web app that consists of a few small packages (pic, wc, ...). If you want to see organization of a big Go app see Camlistore. Both of these are written by Go Authors, so they can be considered nice examples.
I just have to say that writing small, reusable, and separate packages is very common in Go, and that reduces the size of the main codebase of apps.