Jump to content

judda

Administrators
  • Posts

    354
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by judda

  1. Just a heads up - we saw a post by @PaulSonny was made on LinkedIn saying he was looking for development work (https://www.linkedin.com/posts/paulsonnycook_im-actively-looking-for-a-full-time-net-activity-6618932547869118464-ezyI), this means he may come back to our community to try to get paid for coding. I would be extremely wary about doing any work with him. Please see the community thread about his history: https://thegaminglist.com/topic/1422-missing-in-action-paulsonny/?tab=comments#comment-7157
  2. Ah yea, VBA is always going to be there for lovely macros and stuff. I completely agree with that one - it's a good language but not so much for full on development anymore.
  3. @DaRule You use it still frequently? The closest that I get is VBScript in our lovely legacy applications.
  4. At work this week, I saw a phone book which then made me start a conversation about old technologies that we used. The first actual programming language that I used was Visual Basic 6, made a few programs on there with my friends in high school, afterwards we did Java. How about you?
  5. @DaRule - That looks pretty awesome
  6. Recently I've been on a bit of a Podcast kick, finding and listening to a bunch (some of which I listen to end to end). Here are the ones that I'm actively listening to: Art of Product Full Stack Radio Code Newbie Podcast Base.Cs Podcast ChangeLog Coding Blocks Podcast Syntax.fm BaseCode Podcast Zen Founder Laracasts Snippet How about you?
  7. I was listening to an episode of Coding Blocks podcast, and they pointed out something huge that I didn't realize until I heard it about the license for code available on Stack Overflow. Excerpt from their podcast notes: If you use code from Stack Overflow, you need to give attribution to the person who wrote it (and where it was) but also need to change your license to the same license that they have! This is kinda huge because I know of how much of an invaluable resource Stack Overflow is for developers, I use it fairly regularly in my day to day work if I have questions or just want to see an example.
  8. So you have dreams of starting your own Pet Site, but have no experience with programming whatsoever, this thread is going to walk through a lot of things that you need to know, and what you need to look for from your developer (and in your code base), to ensure that you are paying for things that really matter. Please Note: This is not an exhaustive list, this is meant to be a jumping off point to help improve your overall familiarity with the process of developing code. Executive Summary As a site owner, it is your responsibility to know at least at a cursory glance how it works. Code is complicated but so is owning a site. There are a lot of resources out there which can help you, don't treat coding like a black box because at the end of the day you will be the one out money should the developer decide to cut corners. Please Note: As an owner, nothing is "above your pay grade", you are defining the pay grade, so you need to be aware of the inner workings! Best Practices: No live code updates - Yes, cPanel has a code editor built in, or your developer may have an FTP client installed on their computer that they can use to connect to your site, but you should not let them develop through these tools. They are meant for small changes, not developing whole features. Why is this bad? Your users can see things that they shouldn't have visibility to, and it may make the site seem less stable because they are on one page and they see an error message, or worse, raw code emitted (i.e. SQL statement), now you are giving them too much information! Nightly Offsite Backups (or more frequently) - servers die, databases get hacked, accidents happen! Having backups of all of your assets are paramount to recovery. If you happen to keep the backup in the same data centre, or even worse, the same server, you could be asking for trouble. If your server dies (it happens from time to time), the backups that you have stored on the same server will have died with the rest of the code. So this is kind of useless. It's great if there is a quick rollback that is necessary unfortunately in situations like that this is typically not the case. Source Control Everything - So first of all, you are probably wondering what Source Control is, it's a tool that developers are able to use in order to keep track of changes that they do to the codebase, in order to make it easier to work with other developers, as well as be able to revert the code to a point in time when it was actually working (or at least look at it at that point in time). Think of it as "CTRL-Z" on steroids. This one here somewhat goes hand-in-hand with point 1, about no live editing of files because your production environment should be made from either a "release" branch/tag, or your "master" branch in your repository. A great overview of Git is available here. GitLab: https://gitlab.com/ GitHub: https://github.com BitBucket: https://bitbucket.org/product/ Test all code in a Development Sandbox - New code poses the possibility of new bugs (or old bugs rearing their ugly heads again). Because of this, there should be another environment that can be pushed to first prior to production in an attempt to find any bugs early, especially if they are game breaking ones. All changes to the database should be done via code (SQL scripts or migration scripts) - Now that you are following some of the other best practices, we need a way to ensure that the structure in the development environment matches the production database environment. By scripting it (and running the script when deploy time comes), you are able to fairly confidently say "yes, this will work in production". Yes, you have phpMyAdmin, it's a great tool, just like the other things built into cPanel, but if someone makes a schema change in production that isn't reflected in development, then anything you build from that point on (if they rely on it) could potentially be broken because you manually changed something in production. Application Frameworks: So you have a developer that wants to use a framework, should you let them? Probably! First thing's first, what actually is a framework? The regular definition is: A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed. Which fits in really well with what application frameworks do. They scaffold out a lot of the best practices and abstract away lots of the things that you really don't need to have a developer make for you. This in turn leaves you with less code they need to write which should mean more money to spend on the things that matter, and better yet, less security flaws! More frameworks handle things (as best they can) such as Cross-Site Scripting/Cross Site Request Forgery (CSRF) and SQL Injection. These are just two of the big security things that you need to be concerned about. Most frameworks have tutorials out there which range in quality. As a site owner, it is your responsibility to at least know what you are buying a little bit. So I would encourage you to take a bit of time and watch some YouTube videos about it so you can at least familiarize yourself with the nomenclature. Please Note: Just because your developer said that they wanted to use a framework, this does not mean that you do not have to worry about security. Take the following example, you display a "bank" page which to the human eye all you can see is a "withdraw" and a "deposit" text box with a button. But behind the scenes, hidden in the HTML (hidden input field), the programmer decided to also include the user's bank account ID, and use that for any of the actions. Well, in cases like this, your site has a security hole, and the framework has no way of knowing that isn't actually what you want to happen. Lots of the frameworks out there are open source. This means that people around the world can look and work on improving the framework! This means that the framework will have new features added, and security releases made. Because of this, it is super important to keep your version of the libraries as up-to-date as possible. Depending on the language you are using there are a bunch of different frameworks that can be chosen from. We will maintain this list as best as we can, but we will also show you how you can find out the version that you are on, as well as what version the framework is currently on. PHP Laravel: URL: https://laravel.com/ Latest Version: 8.x - https://github.com/laravel/framework/releases Determining your Version: Within the codebase, there should be a file called "composer.json", in there, under "require", there should be a line that says, "laravel/framework". On the right of that, you will see the version you are currently on. CodeIgniter: URL: https://codeigniter.com/ Latest Version: 4 Version 3: https://github.com/bcit-ci/CodeIgniter/releases Version 4: https://github.com/codeigniter4/CodeIgniter4/releases Determining your Version: https://www.kodingmadesimple.com/2016/08/find-codeigniter-version.html CakePHP: URL: https://cakephp.org/ Latest Version: 4.1 - https://github.com/cakephp/cakephp/releases Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be a line that says, "cakephp/cakephp". On the right of that, you will see the version you are currently on. Yii: URL: https://www.yiiframework.com/ Latest Version: 2.0 - https://github.com/yiisoft/yii2/releases Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be a line that says, "yiisoft/yii2". On the right of that, you will see the version you are currently on. Symfony: URL: https://symfony.com/ Latest Version: 5.2 - https://github.com/symfony/symfony/releases Determining your Version: Within the codebase, there should be a file called "composer.json", in there under "require", there should be multiple lines that which start with, "symfony/". On the right of that, you will see the version they are currently on. Because of the nature of this project, they may be on different versions which is fine, however the "major" release should be the same across the board. Python Django: URL: https://www.djangoproject.com/ Latest Version: 3.1 - https://github.com/django/django/releases Determining your Version: Within the codebase, there should be a file called "requirements.txt", in there, should be a line that says, "Django". On the right of that, you will see the version you are currently on. Ruby Rails: URL: https://rubyonrails.org/ Latest Version: 6.0 - https://github.com/rails/rails/releases Determining your Version: Within the codebase, there should be a file called "Gemfile", in there, there should be a line that says, "gem 'rails'". On the right of that, you will see the version you are currently on. If the framework that your developer wants to use isn't listed here, that isn't necessarily a problem, try to get the details about the framework that they are wanting to use, and go from there! It's a great place to start a conversation to make sure you truly are getting what you paid for. The things listed above (especially the latest version) also helps to show how active the project is. If the developer wants to use a framework that hasn't been updated in 3 years, chances are the maintainers of the project have abandoned it, so you probably should too! I used a framework but I still got SQL Injected! Similar to my other example above with the bank, just because you are using a framework does not mean you will not be hit by SQL injection! My gut instinct when I hear this is "the programmer is using it wrong". Most frameworks provide wrappers around the database objects, and then behind the scenes use database parameters to actually query the data. What are database parameters? They are a way of passing the data you want to query (normally user's input) in alongside the actual query, preventing evil-doers from doing things that were not intended (i.e. dropping tables). In the past, developers would just build a string and do something like "mysql_real_escape_string" on the data to ensure the safety, it is still possible in modern frameworks to have access to the raw database object and run queries you write yourself. It's these circumstances that tell me the developer is using it wrong, hence my original statement, the developer is using it wrong, and should be stopped. Please Note: Frameworks are just code, so they do have the potential for bugs which can introduce security issues as well. Take Laravel for example this past summer they found that one small piece of the code was vulnerable to SQL Injection! My Programmer doesn't want to use _____ A framework - Ask why not, prompt them to give answers and don't just settle for "I'm more comfortable in my own code", or "It'll be faster if I code it from scratch" - frameworks this day in age are pretty darn fast, unless you are using it wrong, http://www.phpbenchmarks.com/en/comparator/framework, they likely won't be your bottleneck in the application, it's the rest of the stuff that goes on. Don't throw away the security of your application just because it's easier for a random developer to do their own thing (that no one else will be able to figure out easily). Source Control - Ask why not, there are so many tutorials out there nowadays it's pretty easy to learn. If you are ok with not using it, make sure you discuss your safety net, i.e. when you will pay for things (paid on delivery with code clearly available). Source control is only as useful as the developers using it. They should be committing to it regularly, not just when the code is complete. This will help to give you a good sense of the work that went into the project as well! Payments My personal mantra is, never pay for something that only resides on a development machine. Just like art that is being created, you wouldn't be happy with receiving and paying for a watermarked image. Why are you doing that for code? In your agreement with your programmer, at the bare minimum, state "the code must be stored in this repository". Please Note: You should be the owner of the repository, not the developer. I have seen so many projects go haywire and owners get screwed out of their money because the code hasn't been delivered. It resides on a developer's machine or their personal servers. The repository is just like getting access to the raw PSDs for art (which you should be getting as well when you commission art in case you need to edit things later on).
  9. lol - worth a shot those are the only know people I know that actively work on Mysidia
  10. @SilverBrick @Dinocanid Are you looking for some work on Mysidia?
  11. Shulk is my main - I'm pretty bad but worth a shot
  12. @Justin thank you for the patience, we do own all of the art that was created for us. Over the last little while we have been cleaning up lots of the historical artwork that is there. I do not have numbers for how many need to be replaced off hand though.
  13. @Justin 1 - No 2 - No 3 - None - the code is pretty easy to understand once you look through it. The code for the layout updates is a lot easier to understand and a lot more self documenting. Yes I would be willing to do that.
  14. As previously mentioned, I have a number in mind however, I am not sharing it in order to get offers. 1 - Gold Accounts and ICE Purchases should be able to help sustain it for it a bit however, may not be able to pay for a ton of art at the same time. The budget for a year depends on your overall expenses. I am a programmer, so all I needed to do was pay for hosting and art. 2 - I have no control over what the owner does however, I do believe that if you cleaned house, the community would not like you as a lot of the staff are long time members who love the site. If I were the new owner, I would not do this. 3 - It is all held under my sole proprietorship.
  15. @Mobotropolis I have a number in mind however, at this point I am not sharing it with anyone in order to not muddy the waters.
  16. Hey All, First and foremost, I want to say thank you for the last 5 years! Your continued support and friendship has meant a lot to me. Unfortunately, I come to you today to inform you that IcePets.Com is now going up for sale. Although the website is up for sale, the team is continuing to add new Items and run events. The only thing on pause will be any new features and the progress of our alpha website. All I.C.E. purchases will continue to go back into the site as it always has been, but we understand if the site for sale gives you reason to pause in purchasing. Our goal is to continue to give you a fun place to play as well as events to keep you busy. You have given us many great years, and we hope with a new owner IcePets can give you many more as well. Why is it up for sale? Since purchasing IcePets.Com in 2014, the amount of time that I am able to devote to IcePets has dropped to the point that it is no longer fair to the most important part of the site. You, the users. I (and the rest of the team) have put countless hours into IcePets and definitely do not want to see it fail. That is why I'm looking to sell IcePets to find a new owner who has the passion that I once had and drive the layout updates past the finish line. What Are the Layout Updates? The original code for IcePets was written back in 2009 back when PHP was a much different language. There was no "composer" to install third-party libraries into your code, or anything. It was also coded with a bunch of back doors by the original developer. Because of this, the goal was to give the whole site a fresh coat of paint. The problem was to do this, we needed to change how the pages were built. They moved from being dynamically created in a PHP script (as a string) and being emitted with "echo", to use a full templating engine (twig) to handle them. In the meanwhile, we also improved some of the functionality (i.e. galleries were made nicer, and quick stock now works with every location instead of just your shop). These changes are all available here: icepets.dev. The majority of this is complete, including the biggest thing which were the items, just a few kinks need to be worked through, and enhancements made. So although this was branded as layout updates, after going through the first round, I quickly realized that it was going to be bigger than I had anticipated. What you get: A highly motivated and flexible team to work with Ownership of all of the art assets Pets - 17 Species with up to 37 different colours Trophies - 600 different Items - 4,500 World Maps Avatars - 770 Features: Adoptable pets Forums Messaging Multiple Flash games (most rebuilt using Construct 3) Weekly Raffle Trivia Trophies User Profiles Wishlists (layout updates) NPC + User Shops Trades Quick Stock (way better version in the layout updates) Technology Stack: The technology stack is currently in flux between the live site, and the layout updates. All of the code is stored on Gitlab for the purposes of source control. Live Site: PHP 5.6 Mysql Database jQuery VueJS Must use Apache Support Site: Laravel 5.2 VueJS PHP 7.1 Slack Integration Staff Site: Laravel 6.2 PHP 7.3 VueJS Slack Integration Slack Bot: Laravel 6.2 PHP 7.3 Discord Bot: Laravel 5.6 PHP 7.1 API Site: Laravel 6.2 PHP 7.3 Job Site: Laravel 6.2 PHP 7.3 Layout Updates (in the main repository): PHP 7.3 VueJS Twig Templating Engine MySql Must use Apache HTML 5 Games: Built with Construct 3 Please Note: The API and Job Sites could be merged into one application, this was originally split up so that we could scale up the API infrastructure if needed without running the risk of having scheduled jobs run multiple times. There are tools out there now (i.e. Laravel Vapor) which would automatically handle this for you instead of having it split out this way. Additional: I recently purchased a 6-month subscription for Laravel Shift (Shift CI Plan) which allows for the automatic dependency upgrade of any number of Laravel applications, as long as they are currently on running Laravel 6.0 or above. As long as I have that subscription active, if you do not have any issues with me having access to the code, I am more than willing to have it set up as one of my projects to automatically receive the upgrades (PRs will be submitted from time to time). Also, if you upgrade the other applications to Laravel 6.0, I can enable it for those repositories too.
  17. @Dinocanid - You can't unset $this because it's a PHP object that defines itself. The only way to do it is to unset the variable using the object. That will free it up.
  18. @Digital based on this thread - could we have @PaulSonny's "Programmer" title revoked for now?
  19. You've heard the rumours. You've seen updates. You may have lost faith. But we're here to tell you the layout updates are happening in the very near future! Starting on May 4, we will be opening an Open Alpha Testing Server for all interested Users to participate in finding bugs and working out kinks before the live launch. This will be on an entirely separate server, so your actions over there will not affect your account in any way, but rather serve as a dummy account for you to play around with. The layout updates aim to provide a clean, modernised user interface and improved game experience, as well as large amounts of behind-the-scenes programming to make your IcePets experience the best it can be. We've prepared a preview of some of what's to come! Everyone is welcome to join in the alpha testing, and for your help you'll receive a Participation Trophy. Bugs discovered will be recorded publicly, and there will be special rewards for anyone who brings new bugs to our attention. Please be aware that because this is an alpha test, there may be lag and glitches, which is why we need your help to smooth things out before transferring it all to the live site! We appreciate everyone bearing with us this far. We know it's been a long time coming, and we have heard your feedback in the meantime. After the updates go live, we will be able to refocus Staff resources on new features and games for the future, as well as continued improvements to existing features and artwork. Everyone on Staff is excited for what's coming, and we hope you will be, too!
  20. @Tasinei awesome Can't wait to see the application!
  21. @Tasinei Can you PM me a screenshot of what you see and the error?
×
×
  • Create New...