I'm going way out on the crazy ask limb on this one I'm sure. Has any one made this signature app work in Google App Maker?
https://github.com/github.com/szimek/signature_pad
I've made a paid version of the one from the folks at "App Maker University" work. But it's got some buggy issues when it comes to data source relations in one to many relations. I've done some work around's with the "AMU" version. In the end it's still glitchier than I'd like (signatures not updating or saving, and some overwriting of older signatures). After hours of experimenting I'm at a loss on how to get it to play nice.
Just wondering if this github version would be any cleaner and if someone has a working version in app maker I'd love to play with it.
Related
I've been looking at options for persistence when using RxSwift and Realm was looking attractive due to it's relative simplicity and the availability of some extensions in the community repo.
Unfortunately although I can get Realm and RxSwift working nicely in Xcode 8b6, things of seriously wrong as soon as you try to connect them together as RxRealm does not currently compile (there seems to be more going wrong with it than the Grand Renaming as far as I can tell).
Is there a workaround that is reliable? I can't believe for a moment that there isn't, I just can't find a resource at present. I was thinking of converting the Result object into an Set or Array and making this Observable but. I'm not sure if the contents (Realm Objects) are going to be handled correctly. Knowing my luck, I suspect not!
There's a Pull Request towards the RxRealm project adding Swift 3 support: https://github.com/RxSwiftCommunity/RxRealm/pull/26
I suggest you try using that.
More generally, targeting an Xcode beta will by definition give you a less stable software ecosystem, since no one is submitting apps with that and it's a moving target (often with weekly breaking changes). So if you want stable software, use stable tools. Realm and RxRealm both support Swift 2.2 quite well, so using that will give you the best experience.
A few years back I have been using Titanium Desktop to make an app for Mac. Having been satisfied I came back recently to it for another project, but apparently Titanium Desktop is now TideSDK.
Looking at the reference it seems that a lot of stuff has disappeared, I was mostly expecting more elements in UI, like ScrollView, ImageView and such.
Did they simply vanish from this new release or is it just not fully documented ?
First of all I need to make clear that TideSDK is not Titanium Desktop. While it began on legacy code, more than 1 million lines changes of code have been committed and the SDK has been in existence for almost a year now. You will find a different namespace but API compatibility.
The code base is quite different and has been undergoing major restructuring and improvements. That said, for the end user, it is just as friendly to use. We don't like to go back to discuss the past since we have contributed a body of code that allows developers to run TideSDK on today's modern operating systems. This was only the result of substantial efforts and the continued development of TideSDK by its contributors. If you experience any issues, please file them with on our issue tracker on github.
I've downloaded package TideSDK-1.2.1.RC1-0be9cd89-windows-7-x86-64.zip from tidesdk.org. Installer was found in tidesdk\sdk\win32\1.2.0.RC4\installer. This installer doesn't work: "Installation failed. The installer could not determine the application path."
What's wrong with it? Is it the only (right) way to install TideSDK? No docs on topic were found in resources and links on tidesdk.org.
It looks like you picked up an artefact from our Continuous Integration System from some point in time in development. We will eventually expose a Nightly Build site for developmental releases. That said, we will do this once the 1.3.0-beta is ready so we can properly support you with developmental artefacts.
Please use the legacy 1.2.0.RC4 in the interim that can be downloaded from front page of tidesdk.org until TideSDK 1.3.0-beta is available (which will be along very soon). This will serve your development needs in short term as we continue the work to get the beta prepared.
A new 'Getting Started Guide' will be up later today for the legacy 1.2.0.RC4 as there have been many requests for this help.
We appreciate how much attention our project is getting and have been working hard as a team to produce great documentation. Despite this, our efforts were primarily targeted on the API documentation at the outset. We experienced a surge of interest prior to getting the new guides in place. Our apologies to anyone new that has experienced any difficulty getting started. We appreciate your patience while we fill these gaps.
The new documentation is being prepared in anticipation of the 1.3.0 release so that we have great API docs, guides, and example apps when the time arrives. It is targeted for the end of September. We hope to also have our Tide Builder app available at that time to provide a nice app to help create, run and package your apps. There will also be an enhanced tidebuilder CLI since a tool with a UI will be strictly an option. For those that appreciate minimalism, this will get you going with no more than the SDK and a text editor.
You need to download Titanium Studio first.
Once that's done, you can install the package : Help menu > Install Sepcific Titanium SDK.
We have 4 different environments:
Staging
Dev
User Acceptance
Live
We use TFS, pull down the latest code and code away.
When they finish a feature, the developers individually upload their changes to Staging. If the site is stable (determined by really loose testing), we upload changes to Dev, then UserAcceptance and then live.
We are not using builds/tags in our source control at all.
What should I tell management? They don't seem to think there is an issue as far as I can tell.
If it would be good for you, you could become the Continuous Integration champion of your company. You could do some research on a good process for CI with TFS, write up a proposed solution, evangelize it to your fellow developers and direct managers, revise it with their input and pitch it to management. Or you could just sit there and do nothing.
I've been in management for a long time. I always appreciate someone who identifies an issue and proposes a well thought-out solution.
Whose management? And how far removed are they from you?
I.e. If you are just a pleb developer and your managers are the senior developers then find another job. If you are a Senior developer and your managers are the CIO types, i.e. actually running the business... then it is your job to change it.
Tell them that if you were using a key feature of very expensive software they spent a lot of money on, it would be trivial to tell what code got pushed out when. That would mean in the event of a subtle bug getting introduced that gets passed user acceptance testing, it would be a matter of diffing the two versions to figure out what changed.
One of the most important parts of using TAGS is so you can rollback to a specific point in time. Think of it as an image backup. If something bad gets deployed you can safely assume you can "roll" back to a previous working version.
Also, developers can quickly grab a TAG (dev, prod or whatever) and deploy to their development PC...a feature I use all the time to debug production problems.
So you need someone to tell the other developers that they must label their code every time a build is done and increment a version counter. Why can't you do that?
You also need to tell management that you believe the level of testing done is not sufficient. This is not a unique problem for an organisation and they'll probably say they already know. No harm in mentioning it though rather than waiting for a major problem to arrive.
As far as individuals doing builds or automated build processes this depends on whether you really need this based on how many developers there are and how often you do builds.
What is the problem? As you said, you can't tell if management see the problem. Perhaps they don't! Tell them what you see as the current problem and what you would recommend to fix the problem. The problem has to of the nature of "our current process has failed 3 out of 10 times and implementing this new process would reduce those failures to 1 out of 10 times".
Management needs to see improvements in terms of: reduced costs, icreased profits, reduced time, reduced use of resources. "Because it's widely used best practice" isn't going to be enough. Neither is, "because it makes my job easier".
Management often isn't aware of a problem because everyone is too afraid to say anything or assumes they can't possibly fail to see the problem. But your world is a different world than theirs.
I see at least two big problems:
1) Developers loading changes up themselves. All changes should come from source control. Do you encounter times where someone made a change that went to production but never got into source control and then was accidentally removed on the next deploy? How much time (money) was spent trying to figure out what went wrong there?
2) Lack of a clear promotion model. It seems like you guys are moving changes between environments rather than "builds". The key distinction is that if two changes work great in UAT because of how they interact, if only one change is promoted to production it could break there. Promoting consistent code - whether by labeling it or by just zipping up the whole web application and promoting the zip file - should cause fewer problems.
I work on the continuous integration and deployment solution, AnthillPro. How we address this with TFS is to retrieve the new code from TFS based on a date-time stamp (of when someone pressed the "Deliver to Stage" button).
This gives you most (all?) the traceability you would have of using tags, without actually having to go around tagging things. The system just records the time stamp, and every push of the code through the testing environments is tied to a known snapshot of code. We also have customers who lay down tags as part of the build process. As the first poster mentioned - CI is a good thing - less work, more traceability.
If you already have TFS, then you are almost there.
The place I'm at was using TFS for source control only. We have a similar setup with Dev/Stage/Prod. I took it upon myself to get a build server installed. Once that was done I added in the ability to auto deploy to dev for one of my projects and told a couple of the other guys about it. Initially the reception was luke warm.
Later I added TFS Deployer to the mix and have it set to auto deploy the good dev build to stage.
During this time the main group of developers were constantly fighting the "Did you get latest before deploying to Stage or Production?" questions; my stuff was working without a hitch. Believe me, management and the other devs noticed.
Now (6 months into it), we have a written rule that you aren't even allowed to use the Publish command in visual studio. EVERYTHING goes through the CI build and deployments. When moving to prod, our production group pulls the appropriate copy off of the build server. I even trained our QA group on how to do web testing and we're slowly integrating automated tests into the whole shebang.
The point of this ramble is that it took awhile. But more importantly it only happened because I was willing to just run with it and show results.
I suggest you do the same. Start using it, then show the benefits to get everyone else on board.
Anyone else using this? I've just installed it, documentation is hidden somewhere, and so far it's not doing to well. It's Toolbox tab is missing, and when I add the items manually, they disappear again seconds later. I have managed to get one report done, but nowhere can I find how to make the viewer show it, without a very long winded error about not finding a certain path.
As Mark and Martin already pointed out Telerik support is second to none, so you would surely get help in their forums/support threads. I'm currently working with their Reporting product and honestly I have not experienced any problems so far. I've read that they had problems with the toolbox in x64 bit machines, but it has been resolved in the latest service pack, so you might want to make sure you are using the latest version first. However adding the items manually to the toolbox would definitely work and if you are having problem with that too, it sounds more like a Visual Studio problem to me. Also looking at their system requirements, VS Express editions are not supported, so this might be the case as well.
Looking through their help, I find a whole section about their reportviewer and how to use it - check it out: http://www.telerik.com/help/reporting/aspnetreportviewerembedding.html
You can find the complete documentation and tutorials online in the support section of their site. If this does not help, ask in the forums. And since you have valid license, you can also create a support ticket.
I can't comment on the reporting component, since I have never used it. But I do use the ASP.NET controls and from that I can tell you that you will usually get help very quickly (especially when creating a support ticket).
Telerik offers many useful controls and is generally quite conscientious about their code and support. You're likely to have more luck on their site's forums.
With that being said, I found their reporting tool to be quite buggy and unusable.