The Heroku documentation just says:
A slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system - ready for execution.
Where does the term slug come from? Does it have some origin within the company? Does its use come from the same place as wordpress slugs - ie from the newspaper industry?
I think the name "Slug" derives from Quake computer game terminology. The (non-public) software that Heroku uses to execute user code in dynos is named Railgun (I don't know why). The ammo-type for the railgun in Quake is a "Slug". Thus, the object that the Railgun software deploys ("fires") is a slug.
When we made this part of the Heroku API public we tried briefly to come up with a more self-explanatory name. This was before Docker and containers were really popularized, and I guess we decided that Slug was not too bad a name, and that it was ok for public use.
No, slug is not an acronym.
I believe the name comes from the mollusc:
a tough-skinned terrestrial mollusc which typically lacks a shell and secretes a film of mucus for protection. It can be a serious plant pest.
A slug being the container layer which contains your app's code can be seen as a small thing which lacks a shell (can't be executed without something on top of it, the stack image).
Obviously, slugs don't secrete a film of mucus.
Related
I am having problem loading metaplex store. I did a direct fork from the main metaplex-foundation github master and deployed it on Vercel via their instructions here: https://github.com/metaplex-foundation/metaplex/blob/master/docs/deploy.md
It builds without errors, but when I load the site, it just keeps loading forever and wallet cannot be accessed or connected nor the site be accessible.
I followed all instructions from their link above and ensured I have the address in the.env.
I even added a URL in a new CNAME file I added in packages/web folder, from previous experience.
How can I resolve this?
For starters, metaplex acknowledges that the current storefront (v1) has quite a few issues that are impacting users. No further fixes will be forthcoming given that the storefront has been officially deprecated as of May 2022. With that out of the way, a high level overview of the issue you are describing is as follows:
when you start a storefront (SF) that has no auctions, it needs to scan quite a bit of data to figure out what it needs to display. This scan includes a few chunky calls to the RPC that may or may not work depending on the state of the network. This step is also a bit buggy and can end up in an infinite loading loop.
when you fire up the first auction, SF creates a storeindexer object on the chain. This object is used to index the first auction and all the subsequent auctions.
if SF finds a storeindexer object on startup, it bypasses all the madness in step (1) and instead uses the storeindexer to figure out what data is needed. That doesn’t require any gPA (getProgramAccount) calls either which is nice.
it’s a bit of a catch-22 because in order to start the first auction you need the storefront, but you also need an auction to avoid the loading problem in step (1).
After the first auction is up you should be able to resume using your SF as normal.
You may try this version of the storefront to get around the infinite loading problem. It's quite barebones in terms of functionality and there is an issue with SPL tokens that have decimals other than 9. However it does get around the infinite loading problem and you should be able to list your first auction with it.
https://github.com/neftworld/metaplex-storefront-v1
However, STOREFRONT IS DEPRECATED SO CAVEAT EMPTOR
Please can someone point me in the right direction for what I'm sure is a simple problem, but is causing me to go round in circles.I have three domains
.com
.com.au
.co.nz
I'm trying to keep a single code base for maintenance.
I've done some manual localisation work to change titles, contact details etc based on the url, using request.original_url and stripping out the relevant parts and setting some constants in the application controller (SITE, EMAIL, TELEPHONE etc).
It all works fine, except for my config.action_mailer.smtp_settings in the production.rb.
These obviously should change so the localised email account is used (info#...com or .com.au etc) but
I can't get the constants to be initialised before the environment is loaded. It makes perfect sense why it's not working, but I have no idea how to fix it.
I've tried putting it in initializers, the application.rb and setting it in the production.rb itself. If I move the code anywhere out of the application controller I get a no method error on request.original_url.
Is there a way of pulling out mailer settings so they can be exposed to variables? Or is the production.rb loaded at app start up and after that is unaffected by the end user.
Also, even though the language is remaining the same should I look at i18n for manipulating the site for these features? or is it not worth the effort for the few variables I want to change.
Thanks in advance.
You can just change settings in runtime:
ActionMailer::Base.smtp_settings[:host] = 'yourhostfromrequest'
You could just change the constants in your mailers, since constants in Ruby are mutable.
I've searched around online but can't find what I'm after. Basically, during an install, we fire off a separate executable that basically brute forces a few folders to be read/write enabled for the user group "EVERYONE".
Now, the person that wrote this never took into consideration system language. I had a call with a customer in France that kept failing installation because "EVERYONE" isn't what we would expect.
I'm after an API call to Windows that would return a security group name which would be "safe" to use in a localized environment. Essentially I'm looking to safely edit this code so instead of hardcoding in "EVERYONE", we call a function instead.
The fundamental mistake here is not so much the use of EVERYONE, but rather that the code is using names at all. Instead of using names you should use the well-known SIDs. In your case you need S-1-1-0.
I was hoping to make a Rails app usable both as an Engine and as a standalone Application.
Specifically, I have a nascent app which I'd like to plug in to a customer's site, but ideally, I'd like to just as easily use the app as a standalone system. However, if config/environments/*.rb exist in the enginified version of my app, I get an Uninitialized Constant error at the time the app that I'm having take a dependency on my engine starts up; Rails complains that the MyEngineModule::Application constant can't be found in development.rb, which I think is simply a load order issue, since this does NOT occur when I run the app standalone. If I delete development.rb, the original initializers that reference my MyEngineModule::Application complain, so then I tried to delete those, and all is well.
Great, except that the original app doesn't work, since its configuration is gone.
Is there some tweak I can make to the initialization load order (or load paths, in the Engine < Rails::Engine class definition) that would prevent the original configs and initializers from being loaded when in an engine context, and allow me to leave them in place for the app context?
The simpler answer is probably this, but I'm feeling stubborn, and would like to know what it would take to make my original goal possible:
extract the code for MyEngine into an engine, remove the config/environments/* files and config/initializers/* files, and make the client app depend on this.
Make a "new" minimalist app depend on MyEngine, and move the environment files and initializers to NewApp.
Assuming I feel some unnatural compulsion to keep my original application runnable as it was, if I want to prevent the "engine" from loading the "application" configuration, what's the best way to handle that? I presume this is only really a problem during development, because I can prevent the environments/*.rb files from being pulled into the gem itself, but I like being able to test locally while I'm developing the engine and its client app.
Continuing my tradition of answering my own esoteric questions, it seems like one passable alternative is to include a guard clause in the engine's environments/*.rb and the initializers that goes something like this:
if defined? CuteEngine::Application
CuteEngine::Application.configure do
config.whatever = something
end
end
This gets around the problem of having two Rails::Application objects at a relatively small cost. Not very happy about it, but I'll live.
Bumping this for new comers.
Rails 3.1 comes with mountable engines, which sounds like exactly what you are describing. The docs aren't great for converting existing code, but it looks like this will do what you want:
module CuteEngine
class Engine < ::Rails::Engine
isolate_namespace CuteEngine
end
end
In your other app's routes.rb file, you'll add:
mount CuteEngine::Engine, at: "/cuteness"
http://edgeguides.rubyonrails.org/engines.html#mounting-the-engine
http://railscasts.com/episodes/277-mountable-engines
Due to circumstances beyond my control, my production Camping site appears at mysite.example.com/mysite. I'm pretty sure this is a common Apache / Passenger configuration issue, and I'm not interested in how to fix it right now because the server is out of my control. Suffice to say, the controller for "/" points there and I can't change that any time soon.
Now, for a long time, this wasn't an issue, because R(MyIndexController) points to the correct place. However, I serve my site's CSS using a Rack::Static call to make $SITE_ROOT/public accessible. This means that the stylesheet is at mysite.example.com/mysite/css/style.css. Here's where the problem comes in: the Camping URL() method, when called in my layout, gives http://mysite.example.com, not http://mysite.example.com/mysite. So I can't get it to point to the /css subdirectory, because it's missing a "hop" in the middle. When I run rackup locally, everything is fine (because this file is at localhost:8080/css/style.css), but on the production server I don't know how to fix it.
My question: is there another method (maybe directly from Rack?) that I should be calling instead? I really want to avoid hardcoding it, and/or having a hack to determine whether I'm running locally (for debug) or in production, for every rendering of the layout.
ETA: OK, this gets stranger. Obviously I've abstracted out some of the actual details above, part of which I think I "over-scrubbed". The "top level" URL is actually more akin to /mysite/rest (the developer-centric HTML presentation of our RESTful interface), as opposed to /mysite/management (accounts) or /mysite/ui (JQuery'd / "nice" UI). These are set up in our config.ru, via run Rack::URLMap.new(Hash['/rest' => RestModule, '/ui' => PrettyInterfaceModule, '/management' => UserManagerModule], etc.
So in answer to the comment below, R(Index), from a view in the RestModule, actually returns /mysite/rest/. As an example, I have a "home" link in the layout, which looks like a :href=>R(Index), and generates code that looks like <a href="/mysite/rest/">. The server is configured to serve files from ./public directly at the "site root", so ./public/css/style.css actually does apppear at http://mysite.example.com/mysite/css/style.css, as noted previously. It's that link that I'm having trouble automatically generating, and it's because of the Rack::URLMap that I thought I may have to rely on a native Rack method (not a Camping abstraction) to locate this resource.
So in this case, URL() actually returns http://mysite.example.com/mysite/rest/?
What about something like this?
URL().merge('../css/style.css')
This is an old question so I assume that you did already find a workaround but the new passenger + apache (or ngnix) behaves correctly for camping as far as I could replicate. Your app would be on the Documents root and all the includes in the /public folder so /public/css should be routed correctly regardless of you using a sub folder /mysite or not as passenger doesn't make a difference (again) as far as I can replicate. Therefore this should be easily solvable with passenger 3 + Apache or ngnix.