It may sound like a really trivial question, But i am developing an Android App with some friends and of course, we use GitHub to collaborate. However, for the server-side logic I am not sure where to store them for collaboration, Do I init a new repo only for those clound functions? Or store them together with my Android app source code?
Generally there is a huge discussion how to do such things. I think that you have to decide by yourself depending of your team structure and technologies used. Personally, once upon a time, I preferred to have them separately, however I then I started to work in huge project which was in one huge SVN repo and it was working good as well. Since than I am not so sure anymore...
In my opinion most important is to align with all team members regarding rules to make them all understand rules and follow the rules in the project.
I can provide you some links for interesting articles/discussions:
link1, link2, link3, link4
I hope it will help!
Related
I have the requirement to be able to present a document on a website, in the browser. (not download it) and well the way I know to tackle this (without paying to third parties software) is an iframe, but that sounds like a really old practice.
I'm currently developing an application on Blazor and .net5 and sounds really wrong to put an iframe in there, can you guys provide me input for better practices or just your thoughts?
Edit
I'm trying to use them to present doc, docx, pdf and pngs in a Blazor application with .net5.
Honestly, after days of research, I'm trying to talk the team into the idea of creating an API dedicated to Docs, and as part of that effort would migrate documents to AWS S3 or azure blob storage.
We will introduce Aspose for rendering and separate the Issue.
Why? because all the solutions I have seen to support doc and Docx in .net5 are really hacky and I can see lacks in terms of security. And I would not recommend anyone to try to do the approach I was looking to do at the begging of this question.
I leave here what experience cause this research was pain and I hope this question can still help someone.
I have to deploy now my app and I was wondering to my self if is a good idea bring apps to production with the account-base package. Wouldn't be better to manage this with our own methods?
I think trying to manage it all yourself is a sure fire way to run into problems in the future. The concept of accounts seems simple, but the implementation never is especially when you start sprinkling in all the extra complexities (registration, resetting passwords, validation emails, 3rd party authentication, role based authorization, complete integration with your app, etc.).
At the end of the day, you dont gain much by spending days (or more) implementing and testing (hoping that you got everything right) that stuff when you could be spending that time on building the next big app. I'd much rather use tried and try packages that have verified by thousands of users across thousands of apps instead of trying to roll my own.
It depends on your purposes and preferences. Since account-base seems to fit well on my projects, I recommend you to get the most out of it and don't waste your time reinvent the wheel.
However, in the scope of meteor, if you want to make changes to the package, you can clone it to the packages directory and modify it your way.
The solution is create as many fields as I want and onCreateUser get them and save this on my ddbb
More info: http://docs.meteor.com/api/accounts-multi.html#AccountsServer-onCreateUser
I am new and I am not sure if this is a place to ask this question.
I developed a web site alone using wordpress framework.
Now, I got a guy who I don't know much to join me to develop the site. We live in different countries and we decide to use Bitbucket for code management.
I do not have any experiences in team working, Bitbucket.
My concerns are:
1. Do I need to upload both source code and database to Bitbucket?
Do you think he will just take all the source code and database and make his own website and become my competitor?
What should I be careful when working in a team? I mean sharing code.
I know maybe I am quite small-minded. I am worried about security problems.
But definitely, I need to have someone to work with me to develop the site.
Please advice and write any sources that are useful for this problem.
Thank you.
I'm not an expert in Wordpress, but the concept still applies:
Source code: yes. Database: no, only the database schema/ SQL scripts to recreate it.
Depends on his ethics. You should reach an agreement with him that guarantees that he won't do so, by writing a contract for example.
Take the following into consideration: coding standards, conventions are followed in naming variables, pages, urls, etc, repository privacy is set correctly, repository privileges are distributed to enable the contributors to do only what they're supposed to do.
I'll leave the rest to you and other fellows on this website to figure out depending on your experience :)
I was looking at some larger scale Meteor applications and was wondering why some of the initial sites do not seem to use meteor.
As an example when you go to classcraft and look at the main website you notice it is not using meteor.
Then when you go to their actual application (click signup for example) you can see it uses Meteor.
So they make a clear separation in terms of technology. Can someone explain the reasons? Is it not as efficient / clean to just use Meteor for the whole thing.
Thanks,
Jean
Each company makes their own decisions on how/when/where to use technologies. In the case of meteor, the really strong part of meteor is that it's real-time updating. That means things like messaging systems, getting updates out quickly, etc. good uses for meteor.
It appears as though classcraft has decided they don't need that capability on the home page. There's also some concerns with SEO and meteor that perhaps classcraft didn't want to deal with.
Finally the home page not being built in meteor shields the DB from public view, which is not a huge security advantage, but may be one they considered.
This is all me finding reasons for them as I don't know why they'd make that decision. I don't make that decision for my sites/apps but that doesn't mean others might not see things differently.
I'm the founder of Classcraft. To answer your question, it's because we didn't need everything Meteor had to offer for the front-facing website : reactivity, flexible templates, a database, etc. Meteor is amazing for building apps, but it's overkill for a static website. Also, if the front-facing website was built within the game app, it'd mean that any copy changes or tweaks to the front-facing would cause us to have to redeploy the app, which means some downtime (not much, but still) for our users. Keeping them separate also allows marketing people (who aren't developers) to tinker with it without going into the code base for the game.
We decided to build the front-facing website using middleman. Middleman allows you to generate a precompiled static website, which allows for amazing speed and simple server configuration (it's served from S3, which means it's super fast).
I'm sure the reasons are different for everybody, but that's what it was for us.
Shawn
We're looking into implementing an issue tracker for our web agency. The problem is that most issue trackers seem to revolve around the assumption that an issue is a bug, whereas in a web agency environment, a lot of the issues (request, or whatever you want to call them) are about changes and additions to a current web site.
It also seems to me that a lot of issue trackers assume that you're working on one main software project, and uses that project as the focus of the tracker. A good issue tracker for a web agency would be one which puts each separate client and their issues at the heart of the system, making it easy for them to track and report issues.
Does anyone know of a good issue tracker for the web agency workflow? What are other people using?
In my experience, issue trackers are so closely coupled to the workflow of the organisation that what works in one place may be a complete misfit in another. That said, could basecamp work for you?
We are using Gemini very flexible with the ability to have workflow at the project level.
But where Gemini really helps us is the cross project views. You can view your work across all projects with really good fitering.
Have you had a look at fixx at all? Obviously, being the developer of fixx, I will want to plug it but I know from first-hand experience that a lot of our customers are web agencies who work in a service-oriented environment and need to track more than just "software development" projects.
With fixx, you can define custom issue types (for example "change request" or "Copy changes") and track work against that type.
Unfortunately, fixx still does suffer from the "project-centric" view but a lot of our customers work around this by defining a project per client/website. So, if you were doing web/maintenance on stackoverflow.com, you would have a project called "stackoverflow.com maintenance" and would assign all your users from that company to that specific project. From there, using notifications and filters, it would be very easy for clients to keep track of progress on their specific issues.
FogBugz – it's simple by default, but extensible; it's got an integrated wiki, charts, tags, and you can even tie it to your source-control system (and they also offer their own integrated source control system, Kiln, which is pretty amazing with FogBugz).
Are you using other applications to manage the rest of your business' operations?
I ask because WORKetc has great issue tracking software, and this software is combined with other aspects of business management which can simplify the management process. So not only could you manage all support inquiries and responses in one place, but also your projects, finances, and contacts. Most importantly, it would allow you to use one central contact base for your entire company, while allowing you to reference that contact information (as well as lead information) while working on support inquiries, projects, invoices, etc.
WORKetc's support system works around email integration and simple ticket system (as well as prioritizing) and directly integrates with projects, contacts, and other aspects of the system so that you can save time while responding and managing tickets.
I think especially for the use case of a web-agency, where it's not really about bugs, but mostly (visual) feedback and all of it happens on the web, a visual feedback tool might be the thing you're looking for. Most of these tools will create a screenshot of the webpage and include the given feedback on it.
Some of them also have some kind of dashboard where you can discuss further, or have integrations to other tools like Basecamp (and some them do both).
Here's an article from smashing magazine, which describes a lot of them, e.g.: TrackDuck, BugMuncher. Another great tool the article doesn't mention, maybe because the article is a bit dated, is Usersnap – this one even includes browser extensions.