Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Small dev team, need suggestions for source control and merging

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Small dev team, need suggestions for source control and merging

    The Setup: I was recently hired to help with the front-end of an already in development web application. Up to that point when I was brought on, the project had been solely developed by my boss, who is a back-end guy and needed help getting everything running and looking like the development style guide he was given. I am just fresh out of school, and my boss does not seem to have a lot of experience developing as part of a team. The way we have been doing things in order to get the work that I do merged with the main project is pretty insane. He had been using inline styles on just about everything, so I have been making style sheet tweaks and then going through the files and adding classes to things and removing inline styles from most places. Usually at the end of the week, I will take the stylesheet and any font, image, svg, or other misc files I have been working on, zip up the Alpha Anywhere files I have been working on from within Alpha, putting them on a shared network drive with a README file for him with instructions for where to put stuff, and then having him go through all that to merge my work into the current build on his machine. I have been trying to get us to migrate to a better way to of doing thing but we are on such a time crunch to get this done that he has wanted to wait until this project is over. But doing things this way obviously takes up so much time that it is absolutely worth switching to a proper method if I can create a solid and actionable plan to do so.

    The other problem is this: When my boss takes the most recent build and zips it up within Alpha and then gives it to me to unzip and use, things in the application will be immediately broken as soon as I open the workspace on my machine, before I do anything to it. So thing will look good and as designed on his machine, all the files will be zipped up (and we have tried a couple different things when zipping it up to try to fix this) and then on my machine things like the buttons will be broken and unstyled on the nav, the size and layout of things will be off, the footer will go from black to white. Weird stuff. It is obviously incredibly difficult to do my work of styling things when I am given a build that looks different on my machine than on the boss' where it will be integrated. We so far have not figured out why exactly things are different, but I have suggested that we need to get rid of as many variables as we can by ensuring we are on the same Operating System (he is on Win 7 and I'm on 10), version of Alpha (he hasn't updated in a long time on his machine), making sure project file directory structure is identical, etc, but none of that has been done yet.

    So my questions would be this:
    • What is the best method of version control for small teams developing web applications in Alpha Anywhere? What are most people doing? Are people just using Git?
    • Similarly to above, what is the best practice for pushing merges of two locally edited versions of the project? What are other small teams doing?
    • Lastly, what amount of syncing up should be necessary for the machines of small dev teams? What could be causing my weird problem with things looking different after exporting to another machine? Should we be ensuring we are on the same software version? OS? Something else I'm not thinking of?


    Thanks so much to anyone who can help me with this. My integration this past Friday went really badly and it really made clear to me that something needs to change or this problem is going to keep me from being able to do my job effectively. I appreciate it.

    #2
    Re: Small dev team, need suggestions for source control and merging

    If your boss believes it's not important to create a good, workable environment, then you've already lost and will be banging your head against a wall from now on. The proof for this is his Windows 7 and his version of Alpha. He doesn't want to budge... and either accepts time crunches from his boss... or he creates them himself.

    Waiting for this project to be over will not help. Once project number 1 gets solved, project number 2 gets a promotion and you'll be back for time crunch - round 2... and so on. It's been like this for decades... and doesn't really seem to change.

    Alpha does not lend itself to source control. Some try using Git, but at best you can only sync components, not changes to components. Even then it's not pretty.

    Here are a few things you must do to make your life easier.

    You must both be on the same Version and build of Windows and Alpha. This is an absolute. Working on one project with multiple versions of Alpha will destroy your project.
    You must both start with the same release of your project... working exactly the same way on both machines.
    From then on you cannot work on the same component at the same time. This is not how Alpha works.
    For updates between machines, only zip and send the component(s) you have worked on... not the full project.
    You must be good at recording what changes, and where, you've made to components. People don't like doing this... they feel it wastes time. But then you end up spending twice that time chasing down changes and unexpected behaviours.

    Comment


      #3
      Re: Small dev team, need suggestions for source control and merging

      I work with a couple other developers on an ongoing project and we use Dropbox. It's adequate for our needs. It's certainly not the best solution but for us is fine.
      Mike Brown - Contact Me
      Programmatic Technologies, LLC
      Programmatic-Technologies.com
      Independent Developer & Consultant​​

      Comment


        #4
        Re: Small dev team, need suggestions for source control and merging

        Originally posted by mikeallenbrown View Post
        I work with a couple other developers on an ongoing project and we use Dropbox. It's adequate for our needs. It's certainly not the best solution but for us is fine.
        But how do you use Dropbox?

        Comment


          #5
          Re: Small dev team, need suggestions for source control and merging

          Thanks for the responses so far y'all. In my boss' defense, he is used to working alone and I think he just doesn't understand the importance of getting our machines configured in the same way. When zipping up files, should the "Include absolute path names in zip file" option ever be selected? Should any special options be selected when unzipping? Also, when I have worked on a grid component and then zipped that up and given my boss the files and he has then copied the files into the root project folder, when he goes to preview the build the grid components will give errors instead of displaying, UNLESS he first opens up the individual components in Alpha and previews them himself. Then they will work. Is there a reason for this and a way around this behavior? Thanks.

          Comment


            #6
            Re: Small dev team, need suggestions for source control and merging

            Originally posted by stephenirving View Post
            Thanks for the responses so far y'all. In my boss' defense, he is used to working alone and I think he just doesn't understand the importance of getting our machines configured in the same way. When zipping up files, should the "Include absolute path names in zip file" option ever be selected? Should any special options be selected when unzipping? Also, when I have worked on a grid component and then zipped that up and given my boss the files and he has then copied the files into the root project folder, when he goes to preview the build the grid components will give errors instead of displaying, UNLESS he first opens up the individual components in Alpha and previews them himself. Then they will work. Is there a reason for this and a way around this behavior? Thanks.
            For zipping components, just use a simple zip... nothing else. You should both be using the same structure, drive letter assignments etc. to make things easier.

            The grid issue is most likely the different versions of Alpha. You cannot use different versions of Alpha for development. Further, who is publishing to your server... and what version is the server at?

            For more Git stuff you can have a look at this - an Alpha webinar - see if it helps at all... https://www.youtube.com/watch?v=rMcl1JRF8qI&t=2815s
            And do a search in the Alpha Anywhere V12 forum for Github - there have been a few discussions.

            Comment


              #7
              Re: Small dev team, need suggestions for source control and merging

              Originally posted by Davidk View Post
              But how do you use Dropbox?
              Sorry... We just place the entire development folder into the DropBox folder. If anyone makes a change we all get it right away. We also know who is working on what so someone overwriting something is never an issue (for us anyways).
              Mike Brown - Contact Me
              Programmatic Technologies, LLC
              Programmatic-Technologies.com
              Independent Developer & Consultant​​

              Comment


                #8
                Re: Small dev team, need suggestions for source control and merging

                So... only 1 person works on a component at a time... and you pull components from Dropbox as they are changed and put them into your project. Is this a synced process between Dropbox and your project folders... or a manual copy up and down?

                Comment


                  #9
                  Re: Small dev team, need suggestions for source control and merging

                  Alpha does not lend itself to source control. Some try using Git, but at best you can only sync components, not changes to components. Even then it's not pretty.
                  I don't understand this statement, but I have been working on a project for a long time with a team of developers and we use Git. It works just fine. As David said two developers can't work on the same component at the same time, Git or no Git. Not sure about OS versions, but David is correct that you and your boss must use the same build # of Alpha, and your web app server must match the developer build.
                  • To use Git you must convert all your components to JSON format, if they aren't already.
                  • You need to convert your xbasic code into a filesystem dictionary/xbasic function library.
                  • You will need a to utilize the .gitignore file so that certain file types are not copied:


                  Code:
                  # Ignore adb, alb, alm, aex, wcp_settings, webpublishhistory, recent_files
                  *.ADB
                  *.ALB
                  *.ALM
                  *.MUF
                  *.AEX
                  *.wcp_settings
                  *.backup
                  *.a5hist
                  *.WebPublishHistory
                  *.recent_files
                  lastSelectedProfile
                  __staging.staging/
                  __iispublishhistory.iispublishhistory/
                  /backup
                  componentTypeCache
                  # Uncomment and set next line to your /projectname_History
                  Using Git works well if you follow the above guidelines.
                  Peter
                  AlphaBase Solutions, LLC

                  [email protected]
                  https://www.alphabasesolutions.com


                  Comment


                    #10
                    Re: Small dev team, need suggestions for source control and merging

                    Originally posted by Davidk View Post
                    So... only 1 person works on a component at a time... and you pull components from Dropbox as they are changed and put them into your project. Is this a synced process between Dropbox and your project folders... or a manual copy up and down?
                    The project folder is in the dropbox folder. No need to copy components back and forth. If I make changes to a page, component, etc. everyone has that change right away.

                    And yes, only one person works on a component at a time.
                    Mike Brown - Contact Me
                    Programmatic Technologies, LLC
                    Programmatic-Technologies.com
                    Independent Developer & Consultant​​

                    Comment


                      #11
                      Re: Small dev team, need suggestions for source control and merging

                      That's interesting, Mike. I take it there are no issues with workspace files (adb/alb/alm/alx) constantly being "modified" every time you do something.
                      Peter
                      AlphaBase Solutions, LLC

                      [email protected]
                      https://www.alphabasesolutions.com


                      Comment


                        #12
                        Re: Small dev team, need suggestions for source control and merging

                        One advantage over Dropbox using Git is you have redundancy. You can store extra copies, versions, etc. You have the master copy in the cloud and each developer has one or more copies. But dropbox is a lot easier to set up if that works.
                        Peter
                        AlphaBase Solutions, LLC

                        [email protected]
                        https://www.alphabasesolutions.com


                        Comment


                          #13
                          Re: Small dev team, need suggestions for source control and merging

                          Originally posted by Peter.Greulich View Post
                          That's interesting, Mike. I take it there are no issues with workspace files (adb/alb/alm/alx) constantly being "modified" every time you do something.
                          We haven't had any. We're all on the same page when it comes to development. We all get along, etc. The relationship between devs is half the battle. And like David mentioned earlier we comment the heck out of everything. Makes tracking down bugs a lot easier. Especially when debugging another devs code who likely does things a bit different than you're used to.
                          Mike Brown - Contact Me
                          Programmatic Technologies, LLC
                          Programmatic-Technologies.com
                          Independent Developer & Consultant​​

                          Comment


                            #14
                            Re: Small dev team, need suggestions for source control and merging

                            Originally posted by stephenirving View Post
                            The Setup: The way we have been doing things in order to get the work that I do merged with the main project is pretty insane. He had been using inline styles on just about everything, so I have been making style sheet tweaks and then going through the files and adding classes to things and removing inline styles from most places. Usually at the end of the week, I will take the stylesheet and any font, image, svg, or other misc files I have been working on, zip up the Alpha Anywhere files I have been working on from within Alpha, putting them on a shared network drive with a README file for him with instructions for where to put stuff, and then having him go through all that to merge my work into the current build on his machine.
                            I think using first inline style is a good practice. It is easier to use inline style when you develop. I base my opinion to the fact that I like to style that way. So for example when dealing with Boostrap I first use Boostrap base classes normally and then do some changes using inline style. And when everything is ready I change inline style to css classes and so on and put these to a separate for example site.css file. And then Media Queries if needed.

                            Comment

                            Working...
                            X