useringo / ringo Goto Github PK

Because this will be running across multiple Macs, will need to find a way to allocate a Mac ngrok url to the user session.

localtunnel tunnels tend to expire, but the load balancer doesn't catch these events. Instead of changing the load balancer/build-server to accommodate localtunnel's unreliable system, it would be a lot easier to switch back to ngrok.....

Need a way to track all of this stuff, and find out what's breaking when, as well as what's working when.

https://keen.io/

Of course, the Mac server that will be actually running this code will have more double than the amount of RAM my development machine has, but this is a dangerous scenario.

Basically, when someone has a project that has a huge number of files or a set of super large files, pulling the file contents down from the server becomes risky. The response variable gets too large for the machine to store in RAM, and causes the node server to crash.

Maybe implement a way of storing the response in an external database (like Firebase, although the Firebase would probably run out of memory), and then respond with the contents of that database model later on?

Worth a shot, but this is definitely an issue that needs to be solved soon.

Right now it looks ugly, like Xcode.

For now, the production version of Ringo is running on a single 2010 Mac mini. This Mac mini will not hold up forever, so I'll probably need to buy several cloud macs at some point.

Any free alternatives that might be more reliable?

Whenever a super huge project's file tree needs to be returned, a lot of the time is spent waiting for

1. the data to get from the server to the client (I think from loadfiles)
2. the /get-project-details endpoint to get the details (I think this partially has to do with it, but its probably the above)

No clue why this is happening. So far not proving to cause any major crashes or issues.

The build-projects directory will fill up pretty quickly, and Mac server don't have unlimited amounts of space. Should probably write a script that has a listener that watches the amount of space the build-projects directory is taking up, and probably delete the temporary projects every 24 hours or so (maybe more often depending on how fast it fills up).

This seems to be happening only with the ringoMDATemplate.

This code used to break from every so often mainly because the API layer around the Xcode toolchain was written with some very bad Node.js code. Some of that was due to my lack of knowledge of Node's asynchronous handling at the time. The back-end needs a major rewrite and it should probably be written in Flask or some other similar synchronous framework for a more understandable codebase.

This is an issue, because not only are you overwriting a file (which may not be that big of a deal, especially if the user intended to do so), but the Xcode file adder bash script adds another file path to the .xcodeproj file. This is an issue because Xcode looks for two files that are in the same location, and as a result gets confused.

Need to add a way of preventing a user from creating a file that already exists.

This is a problem. If a user generates a file that they do not want, they'll run into big problems because they won't be able to delete.

For now, I believe Xcode is fine if a file doesn't exist (simply rm -rf'ing a file should be enough to get rid of it without Xcode spitting out linker errors)

Still need to look into this, though.

The above is an example of the kind of code that prevents anyone else who would be interested in using this app from executing the code.

FIX ASAP

Something is getting cached. I'm sure of it.

Ringo needs a better, and more reliable ngrok module in order to expose itself to the Internet.

Currently ngrok, and ngrok-daemon are both unreliable. Need this fixed.

Still waiting for the Appetize team to update their simulator servers to support the new iOS 9 builds.

You get dependency issues, mainly because the cocoapods need to be reinstalled.

Need to do what this guy does:
http://stackoverflow.com/questions/22328882/xcode-5-1-no-architectures-to-compile-for-only-active-arch-yes-active-arch-x

This will help users figure out whether or not they want to use a sandbox or modify/edit a project.

Some of the fonts are getting pulled from CDNs which are a little slow, and some fonts aren't even imported, such as Roboto Condensed. O_O

So many bugs. Needs to be fixed before production.

Currently it just shows a ton of base64 encoded data within the editor, which is useless. The user should be able to see a preview of their image.

Need to implement this (and it should be easy to implement too).

Current installation instructions don't actually teach you how to install the server. Instead just causes more things to break.

I tried setting up the Ringo build-server on a new Mac, and found that the XcodeProjAdder helper script wasn't installed. Needs to be fixed.

Currently, if I mess something up in Xcode, Xcode is very good about showing me the line that is causing the app to crash and gives me a shorthand or explicit error. This is very useful. Ringo currently prints out 99% of the other random logs that Xcode runs when debugging an app. This needs to be fixed soon.

There are only some minor differences, however, this still needs to be fixed soon.

_Sandbox UI_:

_Project UI_:

Currently it just shows a file with some commented sections on how to use Ringo.

Two possible solutions that could make Ringo seem a lot friendlier to use on startup could be:

1. An introduction modal that pops up the first time you use Ringo that has some nice greetings and some helpful tips and links on how to learn Swift, debugging, using Ringo, what each of the buttons do, etc.
2. A landing page which describes some basics about Ringo, why it's been built, why it's so awesome, etc.

Probably both of these solutions should be implemented, but for now, these are just ideas.

Not sure why this is happening. This has never occurred before, and there are no new changes to the code that should cause such a warning. Also, not sure what listeners are causing the memory leak.

If the localtunnel server "occasionally" goes down for this long, that will cause a lot of confusion
http://puu.sh/jSVLY/89ff9e9b73.png

This shouldn't be that hard if you look at it from a hacker's perspective. Simply run the iOS app through either the Appetize simulator or your own native simulator, and then have the Ringo server generate an APK that has a webview linked to the Appetize/iOS simulator's stream.

It would be cool, and fairly easy to build. It would be useful for on-device testing purposes for those who don't have iPhones or Macs to build their iOS apps from.