Often during development designs get updated and we want to avoid this. Interesting how other people freeze figma version and whether it's possible. We need somekind of snapshot link which can't be changed neither by designers nor by developers.
when you give the link, you have the options to set the permission. change permisiion to view only for other users that see your screens created in Figma.
Currently, there is no such way to share the file version wise. What I do in this situation, export the Figma document & rename it something like "app_design_v1.0_02_feb.fig".
And then share the file with devs and other stakeholders. Telling them to import the file on their own.
Another solution is to use "Pages". Though it's not very handy for large design projects. You can name your pages as "app_design_v1","app_design_v2" etc. So that everyone knows what they have on which version.
Related
i couldn't find any information on google for this so i thought i will just ask this general question.
we are developing a web app for customers who can change colors, fonts and stuff in their account through a simplified CustomDesigner (the name) Tab where they can pick colors from a color picker and fonts from a select-box and all this stuff.
currently all these dynamic changes are written through PHP in the CSS but we are working on a complete redesign and rework of the app and want to use the power of SASS for this.
my question is: is it possible to run ruby on a debian server and everytime a user changes some preferences in their account that ruby will compile the generated sass file or the "changed" variables into a new css file completely automatically?
if yes: how? i couldn't find anything at all about this topic.
if my using-example is not good enough and you can't imagine what i want:
think about the custom-bootstrap-builder, where you can simply change all the stuff from viewport-grid-size, fonts, font-sizes, border-radius and all that kind of stuff, and if you click on "download" it delivers a complete bootstrap version with your preselected preferences and downloads it completely automatically.
the download for my use-case is not necessary, instead i want the server to store that "compiled" file in a specific directory on the server and of course import it to the generated HTML.
after some more research and investing more time i found some "module" for nginx which is capable of processing less/sass/scss server side with nginx/LUA
https://github.com/titpetric/nginx-lesscss
i also found a PHP variant to use
https://github.com/leafo/scssphp/
i couldn't try any of these two, but it looks quite promising and i wanted to share if someone else has the same problem.
I was just looking into referencing css files in a theme, that reside in a different database and I was wondering:
Could I reference a whole theme that resides in a different database as well with "extend"?
The reason behind that is: Would it possible to keep themes in one central database that can be used by all kinds of applications and therefore, if there should ever be changes to the themes, they only have to be changed in one location and not in every application.
Thank you for your responses in advance.
no I don't think this is possible (happy to be wrong if someone else knows it is?)
to keep all your theme files in a central spot, an XspLibrary in an OSGi plugin is a good solution, however it is a steep learning curve if you haven't done this before. The benefit is once you know this technique it opens the door for 'centralizing' other parts of xpages.
you deploy the plugin to each server and each client if using xpinc, and the every nsf can use a theme from that plugin.
there are a few 'getting started with xpages plugins' articles popping up around. check through planetlotus.org (I'll edit this answer later with some links)
once you know how to do an XspLibrary, you can then download the source code of the bootstrap4xpages project on OpenNTF to see how they are serving up their theme from a plugin.
it relies on the Extension library though so if you don't use the exit lib you could reverse engineer the necessary parts of that project too!
this bootstrap project was set up by Phillipe Riand who was the chief architect of XPages, so it should be a good example!
I am halfway through creating a video series on doing a theme from a plugin but have temporarily lost motivation :(. I might finish it sometime this year, if I do I will post a link to it on this answer. in the meantime I am happy to answer any questions you have about it if you want to give it a go.
otherwise, a quick and dirty solution would be put the theme files / CSS / images directly on the file system of the domino server, where the other theme files are. 'Mastering XPages' might have some advice about this but I don't have it with me right now :)
I think the short answer is you won't be able to load just a theme from a different database.
Each NSF has it's own JVM, sitting on top of the server JVM. So you can extend a theme that's sitting on the server, but not one in another NSF.
XPages Single Copy Design loads a theme from a different NSF by effectively loading the template's JVM. So it's the theme, but also all other design elements.
Jesse Gallagher's done some work in OpenNTF Domino API to allow you to load an XPage or Custom Control from another database, but I'm not sure if that would work for a theme.
If you want to design once and use in many, you can add the theme to the server itself. Looks for the OneUI elements to see where you need to store it (or it may be mentioned in Mastering XPages). You can only nest themes to five levels, but you should be fine.
I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.
Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.
Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.
Issues that need to be respected or clarified;
Manual build of a single brand via Idiot-Proof GUI (choose a git
branch/tag, specify a certain brand, configure the app e.g.
IAP-enabled, server-domainname, etc - will be written to the
info.plist)
In previous manual tests, setting the executable name in
the plist didn't work? Sorry, have forgotten the exact problem..
perhaps was only an Xcode Debug buildconfig problem, not relevant to
a distribution build?
Code-Signing?!? Can the profile be specified
on-the-fly? Some brands need to be built with the customer's own
profile.
My personal feeling: Hudson or CruiseControl + Xcode plugin.
There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?
And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.
So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?
Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).
IMHO you can resolve all issues using different targets of XCode.
Every target will share the code but it could:
be signing with diferent profiles
use diferent plist: this implies having different names..
use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
Build with one click in XCode.
I hope this helps
An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to:
1. Unzip it (change the .ipa file extension to .zip).
2. Change assets.
Update the info.plist (using Plistbuddy command)
Zip it again.
Resign the code.
See this script as a starting point: https://gist.github.com/catmac/1682965
Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Do you need a project management system if you work alone? I mean a project management system that includes issue tracking, wiki, etc.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system), so I am not really sure if I need a project management software, because I work alone.
One useful thing, I can think of, that project management system can additionally give me is linking issues with commits (UPDATE: I've found this feature useful enough: for example, right now I am creating documentation for the new release of my project and I consequently open every issue with "Pending for release" status, then I read the issue's description and then I can quickly view the diff of the commit for this issue - this helps me to see details and write better documentation).
Another one - sharing issues so your users or your employer can view or manage them.
What am I missing? Is project management software necessary when working as the only programmer?
UPDATE: I've thought up another useful thing: In comments we can give a link to an issue or a wiki article with detailed information about the code being commented.
You say you use some organizer software that helps you managing issues. So you already have your custom project management system. Just keep it.
Project management systems does not have to be big, support sharing data or other kinds of documentation. As a programmer you are supposed to use one to make your work organized, but it doesn't matter which one. You can happily use plain text files if they work for you.
Still, if there is even a slight chance that you'll be cooperating with someone, you should try something that allows cooperation... just to know how they work.
Do you need a project management system if you work alone?
Yes.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system).
See. You have a project management system. Why ask?
project management system can additionally give me is linking issues with commits.
That's not necessarily project management. You can easily do that with you version control software.
Read this: http://tortoisesvn.tigris.org/issuetrackers.html
sharing issues so your users or your employer can view or manage them.
That means you're not working alone, if you're sharing something. What are you asking for here? How to share?
When working alone is the key thought to pursue here. When you are alone, you don't have the luxury of having someone else to keep you on your toes. A good "system" is essential therefore in order to help you manage your projects. As to which system to employ, that all comes down to your individual needs, and how much time you want to spend maintaining such a system.
If there is any possibility that you will need to involve someone else, then you need to decide if the system you use will scale to meet your changing requirements. This is also true if you continue to work alone and your workload changes.
As for software, that is almost another question entirely. I personally prefer to use a software tool to track all of my tasks, and to help me to collate data that helps me to determine priorities and task scheduling. That is in a nutshell what project management is all about. When working at home on my own projects, I use a simple Redmine configuration to manage different types of projects. Planning for programming projects, working out the logistics for my wedding, even managing my house renovations. All have been added to my private Redmine setup because I'm too lazy to try and keep paper-diary styled systems updated. At work, I have a more complex configuration to manage the myriad of programming projects we have here, and to manage the dependencies between them.
I've found though, that the most important thing is to ensure that the processes are streamlined, and that the supporting tool can be configured to match the processes. You don't want to have to change your processes because the tool isn't up to par. Also, the tool should not become the sole focus of all of your efforts, therefore it should be configured to reduce the "red-tape" side of things. You only want to capture enough information to describe your tasks, and to determine when they need to be done, who will do them, and when they are completed. Yes, your needs may require more information to be captured, but always try to minimise this, as you don't want to feel like you are always updating your project management tool when you'd rather be working on that latest killer algorithm you've been looking forward to doing! ;-)
I would not want to work without a system like trac anymore, even if I'm the only one working on the project. You should use a version control system of course, no question about that. Then there are two or three things coming up, you also mentioned.
First is documentation. There are lots of different possibilities and a wiki is just one of it. I personally use the wiki mostly for ideas, thoughts and notes. It's easy to put drawings in it, link to ressources in the web and really quickly edit. This can not replace in code documentation you do with source comments or tools like doxygen. And this can also not replace a manual, if the project requires one.
The second thing you'll come across is some kind of todos, let it be bug reports (even from yourself), feature requests, things like that. You can put them as comments in your code or use a list in a text file or your PIM system, but you can also use a ticket system, just to keep track of what you want to or have to do in the project in the future. You can not do everything just now.
Third is the bigger plan, this is not just atomic todos but things trac calls milestones. This has to be written down somewhere.
The great thing about trac now is, you can integrate all these thing you have to do anyway in one tool and even cross link between all the parts. Link to code lines from a ticket, reference tickets in a commit message, use ressources from your repository in the wiki, automatically build doxygen and integrate it and so on. You must decide if you want to use trac for all the things around your project or something else, but you have these things anyway so why not use a system integrating it all? ;-)
I mean a project management system that includes issue tracking, wiki, etc.
I don't use an Issue Tracker, but I practice continuous (not "big bang") integration, and I test (look for bugs) early and often, and I fix any bugs as soon as I find them, so that list of known Issues remains small.
I also have a lot of structure in the source code (e.g. separate projects/assemblies for separate components), so I try to have "the code is the documentation".
The table at What Types of Documents Should You Create? implies that you may not need documentation (e.g. a wiki), unless you're working with other people: e.g. with a manager, testers, and/or end-users.
You may be the only programmer now but will it stay that way forever? I often work alone on development projects but I still track the "to do" list and issues in a simple Access database. Makes it much easier if you need to expand/hand over a project.
You absolutely do, at least for a bigger projects that take a few months. For the past years I tried :
eclipse notepad plugin - just text file - effective
eclipse mylyn tasks - better, enough for one-man-show, but I was still having issues with migration between eclipse instances
youtrack is free and it's like a JIRA but more simple and practical for an individualist
With notepad I was able to focus on current task, but I wasn't able to maintain long term iterations, because without issue tracker I was loosing discipline, dealing with 3 tasks at the same time, not finishing them, etc.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.